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EXECUTIVE  SUMMARY 


To  share  information  among  automated  engineering  design  tools,  a  basis  for  the 
creation  and  use  of  data  interfaces  is  required.  One  segment  of  the  community  interested  in 
building  integrated  design  environments,  the  electronics  industry,  has  responded  to  this 
need  by  developing  neutral  exchange  standards  for  electronic  product  data.  Currently, 
there  are  four  established  standards,  each  distinct  from  the  others,  which  can  be  used  to 
transfer  data  among  automated  tools  for  designing  and  fabricating  electronic  products. 
These  standards,  the  Institute  for  Interconnecting  and  Packaging  Electronic  Circuits  D-35x 
series  (IPC-D-35x);  the  Initial  Graphics  Exchange  Specification  (IGES);  the  Electronic 
Design  Interchange  Format  (EDIF);  the  VHSIC  Hardware  Description  Language  (VHDL); 
and  the  proposed  Product  Data  Exchange  Specification  (FDES)  have  been  developed  or  are 
under  development  by  independent  groups  to  achieve  data  interface  standards  for  distinct 
applications.  As  each  of  these  standards  evolves,  however,  the  users  of  the  standards 
demand  extensions  which  go  beyond  the  original  domains  of  the  standards.  As  a  result  of 
a  lack  of  communication  among  these  independent  efforts,  the  domains  of  these  standards 
now  overlap. 

DoD,  IEEE,  ANSI,  and  EIA  representatives  reCognize  the  need  for  cooperation 
among  these  standards  groups  to  resolve  the  overlap  issue.  Efforts  to  coordinate  the 
evolution  of  the  standards  are  underway.  Effective  coordination  will  depend  on  a  clear 
understanding  of  the  technical  and  political  problems. 

Until  coordination  is  achieved,  designers  of  integrated  design  engineering 
environments  will  continue  to  choose  which  standard  or  set  of  standards  is  the  most 
appropriate  fof  their  integration  needs.  This  choice  is  not  simple.  All  of  the  standards 
represent  some  subset  of  product  data.  To  rigorously  define  these  subsets,  a  thorough 
analysis  of  the  representational  capabilities  of  the  standards  is  needed.  To  achieve  this 
understanding,  the  informational  context  of  each  standard  in  question  needs  to  be  modeled. 
There  are  not,  however,  at  the  present  time  adequate  methodologies  to  fully  model 
engineering  product  data.  Current  information  modeling  techniques  have  been  derived 
from  business  applications  and  are  severely  limited  in  their  capability  to  represent  the 
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complex  and  ambiguous  data  that  is  generated  throughout  the  life  cycle  of  product 
development 

Fundamental  research  questions  regarding  the  representation  of  engineering  product 
data  must  be  resolved. 
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Figure  ES-1.  Timeline  of  CAE  Standards  Milestones 


I.  INTRODUCTION 


Much  work  has  been  accomplished  in  the  last  several  years  toward  the  development 
of  exchange  formats  for  electronic  product  data.  There  are  currently  four  industry  formats 
in  use  today.  Although  the  data  formats  are  designed  to  serve  as  interfaces  among 
application-specific  automated  design  tools  and  data  bases,  they  are  not  consistent  with  one 
another.  Now  that  these  formats  have  been  accepted  to  some  degree  by  the  electronics 
industry,  many  questions  remain  regarding  the  adequacy  and  application  of  these 
standards.  The  basic  issue  addressed  in  this  report  is  whether  this  family  of  standards  is 
sufficient  to  support  open  architectures  for  automated  design  environments. 

A.  PURPOSE 

The  Institute  for  Defense  Analyses  (IDA)  recognized  the  need  for  a  global  and 
unbiased  assessment  of  the  current  state  of  Computer-Aided  Engineering  (CAE)  exchange 
standards  to  achieve  integrated  environments  for  CAE.  This  document  is  the  result  of  a 
year-long  study,  conducted  by  EDA  during  fiscal  year  1987.  This  study  focused  on 
determining  whether  or  not  the  emerging  CAE  data  exchange  formats  will  support  the 
integration  needs  of  the  Air  Force's  Unified  Life  Cycle  Engineering  (ULCE)  program  and 
the  Reliability,  Availability,  and  Maintainability  in  Computer-Aided  Design  (RAMCAD) 
program. 

The  opinions  expressed  in  this  report  have  been  formed  after  extensive  discussions 
with  many  of  the  key  people  who  are  involved  in  standards  activities.  The  opinions  do  not 
necessarily  reflect,  however,  those  of  the  Air  Force,  IDA,  or  any  of  the  various 
organizations  cited  in  this  report. 

The  information  in  this  report  reflects  the  state  of  the  world  as  of  June  1987. 


B .  THE  NEED  FOR  EXCHANGE  FORMAT  ANALYSIS 


Both  programs,  ULCE  and  RAMCAD,  concern  the  development  of  design 
engineering  environments  which  integrate  automated  tools  to  improve  the  quality  of  a 
product  throughout  its  life  cycle.  The  objective  of  the  ULCE  program  is 

to  develop,  demonstrate,  and  transfer  to  applications  the  techniques  and 
technologies  needed  to  provide  advantageous,  computerized  integration  of 
the  procedures  dealing  with  designing  for  producibility  and  designing  for 
supportability  with  those  dealing  with  designing  for  performance,  cost,  and 
schedule.  (Implementation  Plan  for  ULCE ,  February  1987) 

The  ULCE  concept  represents  the  future  design  environment. 

The  overall  objective  of  RAMCAD  is  to  unify  reliability,  maintainability,  and 
supportability  (R,M&S)  aspects  of  the  design  early  in  the  design  cycle.  It  is  a  foundation 
of  ULCE  and  supports  the  first  Computer-Aided  Acquisition  and  Logistics  Support  System 
(CALS)  objective  to  integrate  supportability  analyses  into  the  design  process. 

To  understand  why  a  comprehensive  analysis  of  data  exchange  formats  is  needed  to 
implement  ULCE  and  RAMCAD  concepts,  several  elements  of  CAE  integration  technology 
must  be  understood.  These  elements  include  open  architectures,  neutral  exchange  formats, 
product  data,  and  format  implementation  considerations. 

1 .  Open  Architectures 

Achieving  RAMCAD  and  ULCE  depends  on  technical  and  non-technical  factors.  A 
key  technical  problem  is  the  design  and  implementation  of  open  architectures  (or  "open 
systems")  for  design  engineering  environments. 

Open  architectures,  in  their  fullest  sense,  provide  a  framework  for  integrating 
heterogeneous  design  tools  and  data  bases  in  a  cohesive  environment.  The  key  to  open 
architectures  are  well-defined  interfaces  among  the  various  elements  of  the  environment. 
Basic  elements  of  open  architectures  include: 

(1)  procedural  access  to  databases  and/or  binary  design  files, 

(2)  documented  ASCII  design  files, 

(3)  standard  update  and  query  facilities, 

(4)  distributed  processing  and  data  access  facilities, 

(5)  design  and  file  management  facilities, 

(6)  process  control, 
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(7)  version  control,  and 

(8)  standard  user  interfaces. 

A  conceptual  model  of  information  requirements  serves  as  the  foundation  for  the  open 
architecture  by  providing  a  precise,  complete,  and  consistent  definition  of  the  information 
requirements.  By  correlating  the  data  represented  by  neutral  exchange  formats  with 
definitions  of  the  conceptual  schema,  neutral  exchange  formats  tie  the  basic  elements  of  the 
open  architecture  together. 

The  CAE/CAD/CAM  vendor  community  has  been  exploring  the  concept  of  open 
architectures  for  the  past  few  years.  Specific  products  which  claim  to  provide  open 
architecture  engineering  environments  are  being  promoted  in  technical  literature  on  a  regular 
basis.  For  the  most  part,  however,  these  products  have  a  limited  concept  of  open 
architectures.  Usually  this  definition  refers  to  the  use  of  standard  operating  systems  and 
standard  platforms;  limited  support  for  neutral  exchange  formats;  and  the  availability  of 
database  access  routines  and  ASCII  design  files.  Instead  of  providing  mechanisms  which 
make  it  possible  to  truly  integrate  (not  simply  attach)  foreign  tools  into  the  system,  these 
products  offer  front-to-back  (functions  for  conceptual  design  through  release  to 
manufacturing)  proprietary  design  and  analysis  tools  in  an  "integrated"  environment  with 
some  hooks  to  link  the  proprietary  tools  to  outside  systems.  An  exception  to  this  is  a  set  of 
products  recently  released  by  a  new  silicon  valley  company,  EDA  Systems.  Their  products 
are  described  as  "a  tool  kit  for  people  to  build  CAD  systems."  (Richard  Goering,  "CAE 
Start-Up  Focuses  on  Data  Base  Management")  The  utilities  provided  in  this  tool  kit  include 
distributed  data  base  management,  design  management  and  version  control,  a  graphics 
user-interface,  and  a  generic  electronic  data  base.  Neither  interface  or  data  base  translation 
tools,  however,  are  provided.  This  product  is  a  close  approximation  to  the  concept  of  a 
generic  "shell"  for  integrating  disparate  design  tools  in  a  distributed  environment.  As  such, 
it  may  represent  a  new  direction  that  industry  is  taking  to  provide  open  architecture 
environments. 

2 .  Neutral  Exchange  Formats 

Neutral  exchange  formats  serve  a  vital  role  in  open  architecture  environments. 
They  are  physical  descriptions  of  the  information  required  for,  or  produced  by,  a  particular 
application,  thereby  allowing  automated  tools  to  share  data.  Such  formats,  by  definition, 
are  not  based  on  any  specific  tool  or  database.  They  are  not  proprietary,  and  they  are 
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designed,  developed,  and  supported  by  various  segments  of  the  user  and  vendor 
communities  in  the  public  domain. 

To  select  the  most  appropriate  neutral  exchange  format  or  set  of  formats  for  an  open 
system,  a  comprehensive  understanding  of  the  representational  capabilities  and  limitations 
of  each  exchange  format  is  necessary.  In  other  words,  the  "content"  or  the  semantics  of  the 
format  must  be  well  understood.  After  identifying  candidate  formats  for  a  particular  set  of 
tools,  for  example,  one  must  determine  what  information  the  formats  can  handle,  what 
information  cannot  be  represented,  what  overlaps  exist  among  the  formats,  what  usability 
conventions  exist,  and  what  extensions  are  proposed  for  the  format. 

3 .  Product  Data 

Comparing  and  contrasting  the  semantics  of  data  formats  would  be  straightforward 
if  all  design  data  formats  were  based  on  a  common  definition  of  product  data.  Product  data 
is  all  of  the  data  necessary  to  describe  a  product  throughout  its  entire  life  cycle.  According 
to  Bradford  Smith  in  US  and  International  Efforts  in  Product  Data  Exchange ,  it 

includes  the  geometry,  topology,  relationships,  tolerances,  attributes,  and 
features  necessary  to  completely  define  a  component  part  or  an  assembly  of 
parts  for  the  purposes  of  design,  analysis,  manufacture,  test,  and 
inspection. 

A  recent  statement  in  the  Development  Plan  for  a  Product  Data  Exchange  Specification  (by 
D.  Appleton  Co.)  describes  product  data  as:  "Limited  to  data  that  describe  the  functional 
and  physical  characteristics  of  each  unit  of  a  product  throughout  its  life  from  requirements 
at  inception  to  its  configuration  at  time  of  retirement."  The  vernacular  underlying  each 
format,  however,  is  unique  to  the  community  responsible  for  the  development  of  the 
format.  A  "signal"  in  the  VHSIC  Hardware  Description  Language  (VHDL),  for  example, 
has  a  different  meaning  than  a  "signal"  in  the  Electronic  Design  Interchange  Format 
(EDIF). 

Figure  1-1  is  an  illustration  of  the  relationship  between  a  common  definition  of 
product  data  and  data  exchange  formats.  This  chart  was  developed  to  explain  the  role  of  a 
conceptual  schema  for  shared  product  data.  A  conceptual  schema,  in  theory,  provides  the 
meanings  with  which  facts  are  interpreted.  For  instance,  if  the  fact,  "8506,"  is  associated 
with  the  meaning  "house  number,"  then  a  datum  has  been  established.  That  datum, 
associated  with  a  specific  need,  can  be  considered  information.  This  issue  is  described  in 
further  detail  in  Chapter  IV. 
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Source:  IEEE,  A  Conceptual  Schema  lor  Shared  Product  Data 


Figure  1-1.  The  Foundations  of  Knowledge 

4 .  Format  Implementation  Considerations 

To  assess  the  practicality  of  implementing  a  particular  neutral  exchange  format, 
several  important  considerations  must  be  made.  First,  it  is  necessary  to  understand  the 
"packaging  details"  of  the  format.  The  term  "packaging  details"  refers  to  the  syntax  of  the 
format,  or  the  way  in  which  the  data  is  structured.  Typically  the  syntax  of  a  format  reflects 
the  programming  paradigm  at  the  time  the  format  was  conceptualized.  For  instance,  the 
IPC-D-350  format  was  designed  when  data  was  structured  for  storage  on  card  images. 
Consequently,  the  IPC-D-350  format  matches  the  ASCII  fixed  field  card  image.  Syntax 
impacts  the  following  characteristics  of  the  format: 

( 1 )  the  amount  of  redundant  data  maintained  in  each  design  file, 

(2)  the  size  of  the  design  files, 

(3)  the  lexical  flexibility  of  the  format  (the  complexity  of  processing  necessary  to 
parse  [read!  and  produce  a  design  file), 

(4)  the  extensibility  of  the  format  (the  extent  to  which  new  semantic  concepts  be 
incorporated  into  the  format  without  jeopardizing  upward  compatibility), 

(5)  the  ability  to  verify  data  consistency, 

(6)  the  ability  to  read  and/or  manually  edit  the  data,  and 

(7)  the  ability  to  store  incomplete  design  data. 
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Other  considerations  impacting  the  practicality  of  a  format  are  based  on  prospects 
for  the  ongoing  support  and/or  evolution  of  the  format.  It  is  not  reasonable  to  implement  a 
neutral  format  for  open  system  environments  which  may  be  abandoned  by  industry  after  a 
short  lifetime.  Indicators  to  monitor  include: 

( 1 )  the  extent  and  nature  of  user  support, 

(2)  the  extent  and  nature  of  vendor  support, 

(3)  ongoing  activities  of  the  development  group, 

(4)  international  support  (European  and  Japanese) 

(5)  the  existence  of  test  and  validation  plans, 

(6)  the  availability  and  quality  of  documentation  and  user  implementation 
guidelines, 

(7)  the  organizational  structure  and  procedures  for  managing  the  evolution  of  the 
format, 

(8)  national  and  international  standardization  activities  (such  as  IEEE,  ANSI,  EIA, 
ISO,  and  IEC),  and 

(9)  the  extent  of  DoD  support  (directly  in  terms  of  funding  and  manpower,  and 
indirectly  in  terms  of  contractual  requirements). 

Chapter  II  compares  these  and  other  features  of  the  leading  CAE  data  exchange  formats. 

C .  THE  STUDY  METHODOLOGY 

There  are  many  categories  of  standards  necessary  for  the  full  implementation  of 
ULCE,  RAMCAD,  CALS,  and  other  programs  dedicated  to  the  development  of  integrated 
design  environments.  For  instance,  the  technical  standards  for  the  CALS  Core 
Requirements  Specifications  are  grouped  into  five  major  categories:  media,  communi¬ 
cations,  transaction  management,  data  management,  and  interface  (see  Figure  1-2).  Other 
examples  of  standards  classifications  are  provided  in  Figures  1-3  through  1-5. 

The  focus  of  this  study  is  on  neutral  exchange  formats  for  electronic  product  design 
data  (also  referred  to  as  electronics  data  exchange  standards).  These  standards  are  a  subset 
of  product  data  standards.  In  CALS  documents,  it  is  a  subcategory  under  the  interface 
category.  Although  this  group  of  standards  is  less  mature  than  others,  it  is  critical  to 
CAE/CAD  integration.  The  type  of  information  incorporated  into  these  formats  include  all 
of  the  data  contained  on  a  circuit  schematic  and  the  corresponding  physical  layout. 


Media  -  Removable,  Flexible  Media 

-  Fixed,  Rigid  Magnetic  Discs 

-  Microimagery 

Optical  Digital  Data  Discs 

Communications  |  Wide  Area  Networks 

(OS I  Levels  1-6)  -  Local  Area  Networks 

Transaction  Management  Operating  System 

— — —  Time  Sharing 

-  Batch 

Security 

Data  Management  Flat  File 

-  DBMS 

-  Data  Dictionary 

File  Store 

Interface  -  Technical  Publications 

-  Drawing  Exchange 

“  Electronics  Data  Exchange 

“ Presentation  Graphics 
-  Text 

-  Engineering  Graphics  Access 

Distributed  Graphics/Text/Data 


Figure  1-2.  Technical  Standards  for  the  CALS  Core  Requirements  Specifications 
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Source:  "Planning  Scenario  for  CALS  Actions,"  27  Oct  84. 

Figure  1-3.  An  Early  Classification  Scheme-  for  CALS  Standards 
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Source:  "Technology  &  Stds  Issues  Relating  to  CALS,"  R.  Hocken,  NBS,  12  Sept  84. 

Figure  1-4.  Another  Early  View  of  the  Standards  Required  for  CALS 
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The  first  task  of  the  study  was  to  identify  the  leading  data  exchange  formats  for 
electronic  design  data.  Three  existing  formats,  one  emerging  format,  and  one  design 
language  were  identified:  the  Electronic  Design  Interchange  Format  (EDIF),  the  Initial 
Graphics  Exchange  Specification  (IGES),  the  Institute  for  Interconnecting  and  Packaging 
Electronic  Circuits  (IPC)  D35x  series,  the  Product  Data  Exchange  Specification  (PDES), 
and  the  VHSIC  Hardware  Design  Language  (VHDL),  respectively. 

After  contacts  were  established  with  the  key  figures  involved  in  the  development  of 
these  formats  and  participation  on  various  key  committees,  it  became  possible  to  track  the 
progress  of  each  development  effort.  These  contacts  provided  historical  perspectives  as  well 
as  current  assessments  of  industry's  views  regarding:  (1)  the  current  and  future  viability  of 
these  formats,  (2)  the  technical  functionality  of  the  formats,  and  (3)  new  approaches  to 
integrating  heterogeneous  design  tools. 

Early  in  the  investigation,  the  criticality  of  the  interoperability /overlap  issue  became 
apparent.  Although  each  of  the  formats  named  above  was  developed  for  a  very  specific 
application  or  set  of  applications,  subsequent  enhancements  have  led  to  overlaps  in  the 
representational  capabilities  among  these  formats.  There  are  no  established  procedures  for 
using  these  formats  together  or  resolving  these  overlaps.  This  has  resulted  in  much  debate 
regarding  whether  these  formats  are  competing  or  complementary. 

There  are  many  potential  solutions  to  the  overlap  controversy.  One  solution  is  to 
secure  an  agreement  among  all  involved  in  the  development,  standardization,  and 
promulgation  of  the  formats  to  define  and  adhere  to  specific  scope  boundaries  for  each  of 
the  formats.  Another  solution  is  to  define  interfaces  among  the  formats  without  a  rigorous 
definition  of  the  commonalities  among  these  formats.  A  third  solution  is  to  develop  one 
standard  suitable  for  all  applications  to  replace  the  existing  standards.  Finally,  after 
precisely  defining  areas  of  overlap,  these  overlaps  could  be  used  as  bridges  from  one 
format  to  the  next.  Each  of  these  possible  solutions  has  a  different  implementation 
timetable  and  different  probability  of  success.  These  factors  are  discussed  in  Chapter  III, 
Section  D. 

The  investigation  led  to  the  discovery  of  three  independent  efforts  in  which  attempts 
are  being  made  to  coordinate  the  interoperability  of  the  standards.  These  coordination 
efforts  are  driven  by  the  assumption  that  these  formats  are  complementary  (not  competing) 
and  are  seeking  solutions  to  ensure  their  coexistence.  Although  the  efforts  are  in  the 
information-gathering/planning  stage,  it  appears  as  though  each  effort  will  be  formulating  a 
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unique  approach  to  solve  the  problem.  These  coordination  efforts  are  described  in  Chapter 
III. 

Chapter  IV  expands  on  the  role  of  data  modeling  in  the  analysis  of  the  semantic 
content  of  the  exchange  formats,  and  describes  the  manner  in  which  two  modeling  projects 
tested  these  ideas.  By  participating  on  a  modeling  team  which  was  attempting  to  develop  a 
conceptual  model  for  electronic  product  data,  an  in-depth  understanding  of  a  popular 
modeling  methodology  and  the  actual  model  under  production  was  attained.  This 
participation  provided  the  background  necessary  to  assess  the  future  uses  of  the  model  and 
the  applicability  of  the  modeling  methodology  to  engineering  design  data  and  CAE 
exchange  formats. 

This  study  was  necessary  to  tie  together  the  various  goals  and  perspectives  of 
diverse  groups  involved  in  developing  solutions  to  the  CAE/CAD  data  exchange  problem. 
The  results  lay  a  foundation  upon  which  an  understanding  of  the  critical  issues  can  be 
based  and  solutions  can  be  proposed. 

Throughout  this  study,  numerous  documents  and  articles  were  collected.  A  listing 
of  this  library  of  Supporting  Material  appears  at  the  end  of  Chapter  IV. 

The  appendices  and  supporting  materials  listed  in  this  document  are  meant  for 
supplementary  purposes  only.  The  appendices  and  supporting  materials  are  trip  reports, 
meeting  reports,  memorandums,  briefings,  and  other  related  materials  delivered  to  the 
Institute  for  Defense  Analyses  in  support  of  this  project. 

D.  TERMINOLOGY 

The  Computer-Aided  Engineering  (CAE)  formats  described  in  this  study  are 
guidelines  for  exchanging  data.  These  guidelines  consist  of  a  defined  syntax  (rules  for  the 
formulation  of  sentences  or  statements  in  the  language)  and  semantics  (meanings  ascribed 
to  statements  in  the  language).  They  do  not  necessarily  impose  constraints  on  the  design  of 
the  interface.  In  other  words,  they  do  not  provide  detailed  specifications  of  what  needs  to 
be  done  to  build  an  interface. 

The  words  "format,"  "standard,"  "specification,"  and  "guideline"  are  given  many 
interpretations.  This  is  a  terminology  problem.  Throughout  this  document,  "format" 
denotes  a  static  data  structure  definition.  Formats  are  guidelines  for  structuring  or 
representing  information.  Guidelines  provide  very  general  directions  for  representing  data. 
Formats  which  have  been  in  use  for  an  adequate  period  of  time,  have  been  accepted  by  a 
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wide  range  of  users,  and  have  been  proven  to  be  relatively  stable  are  referred  to  as 
"standards."  Standards  are  less  general  than  guidelines  and  provide  more  detailed 
recommendations  for  creating  the  representation  for  a  particular  application.  A 
"specification"  is  a  detailed  procedure  which  defines  what  needs  to  be  done  to  create  an 
interface  using  standards  (or  formats).  Specifications  provide  precise  definitions  of  the 
nuts  and  bolts  required  to  get  the  job  done. 

A  "language"  defines  both  a  dynamic  and  static  syntax  and  semantics  with  which 
procedural  descriptions  may  be  written.  The  dynamic  language  constructs  (statements)  are 
executable.  The  static  language  constructs  are  comparable  to  a  format. 

Other  terms  will  be  defined  as  they  are  used. 
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II.  A  COMPARISON  OF  THE  CAE  EXCHANGE  FORMATS 


This  section  contains  descriptions  and  comparisons  of  the  leading  exchange  formats 
for  electronic  product  data.  The  formats  under  comparison  are: 

(1)  the  Institute  for  Interconnecting  and  Packaging  Electronic  Circuits  (IPC)  D-35x 
Series 

(2)  the  Initial  Graphics  Exchange  Specification  (IGES), 

(3)  the  Electronic  Design  Interchange  Format  (EDIF), 

(4)  the  VHSIC  Hardware  Description  Language  (VHDL),  and 

(5)  the  Product  Data  Exchange  Specification  (PDES). 

Comparisons  will  include  purpose,  history,  goals,  application  areas,  information  coverage, 
funding  source,  industry  support,  file  format,  and  future  prospects.  The  purpose  of  this 
section  is  to  set  forth  generalizations  about  the  similarities  and  differences  among  these 
formats.  This  is  not  a  tutorial  on  the  technical  aspects  of  the  formats.  Throughout  this 
section,  references  will  be  made  to  sources  which  provide  technical  details.  Appendix  L, 
"CAE  Standards  Coordination  Meeting  Report,"  discusses  the  individual  standards  from 
the  perspective  of  the  leaders  of  each  of  the  efforts.  The  information  in  this  section  serves 
as  background  material  for  the  remaining  sections.  Table  II- 1  is  a  summary  of  the  basic 
information. 

A.  PURPOSE 

Each  standard  under  comparison  was  designed  to  solve  a  particular  problem,  and 
the  original  scopes  of  each  addresses  a  specific  need.  As  the  standards  have  matured, 
however,  these  domains  of  applicability  have  grown  beyond  the  original  scopes. 

The  IPC-D-35x  series  is  a  set  of  neutral  exchange  formats  to  transmit  printed  board 
descriptions  between  designers  and  manufacturers.  The  original  purpose  of  the  project  was 
to  "develop  a  replacement  for  the  document  known  as  the  Master  Drawing  with  a  magnetic 
tape  that  had  all  the  same  information."  (Dieter  Bergman,  "Long  Range  Plan  for  an 
Electrical  Computer  Format  Standardization  Effort")  The  range  of  data  represented  has 
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been  subsequently  broadened  to  include  electrical  documentation,  electrical  associativity, 
numerical  control  formats,  and  standard  test  data  formating.  The  D-35x  formats  are 
functionally-oriented,  rendering  them  both  human-readable  and  machine-processable. 

IGES  is  a  neutral,  device-independent  data  format  for  the  exchange  of  graphical  and 
other  product  definition  data  among  present-day  CAD  systems.  Initially,  IGES  was  used 
to  transfer  the  "graphical  representation  of  engineering  drawings  between  disparate  CAD 
systems."  (Peter  Wilson,  "A  View  of  PDES")  This  involved  definitions  for  geometric, 
annotation,  and  structural  data.  The  meaning  of  the  data  depended  completely  on  human 
interpretation.  The  current  version  of  IGES  reflects  substantial  enhancements  made  to  the 
capabilities  of  the  format.  These  enhancements  "reflect  a  desire  to  expand  the 
specification's  capability  to  communicate  a  wider  range  of  product  data  developed  and  used 
by  computer-aided  design  and  manufacturing  systems."  (Bradford  Smith,  "U.S.  and 
International  Efforts  in  Product  Data  Exchange")  The  major  capabilities  of  Version  3.0  still 
involve  geometric  models  and  drawings,  although  properties  and  associativities  can  now  be 
used  for  product  definition  data  to  a  limited  extent.  (W.  C.  Burkett,  "Fast,  Good,  Cheap") 

EDIF  is  a  neutral,  public  domain,  and  machine-readable  exchange  format.  The 
original  purpose  of  EDIF  was  to  provide  a  mechanism  for  exchanging  integrated  circuit 
(IC)  data  for  semi-custom  design  between  designers  and  gate-array  foundries.  The  current 
version  of  EDIF,  however,  can  be  used  for  "information  transfer  at  all  levels  of  electronic 
design.. .from  design  capture  and  verification  through  layout,  manufacture,  and  test  of 
printed  circuit  boards  and  application-specific  integrated  circuits."  (Henry  Alward,  "Latest 
EDIF  Version  Marks  a  Milestone  for  CAE/CAD") 

VHDL  is  a  language  which  supports  the  design,  documentation,  and  simulation  of 
digital  circuits  from  the  system  level  down  to  the  gate  level.  Its  purpose  is  twofold.  First, 
it  can  serve  as  an  interface  among  design  tools  by  supporting  the  transmittal  of  digital 
design  data  among  hardware  component  vendors,  design  engineers,  and  manufacturers. 
Secondly,  it  can  document  digital  designs  by  providing  the  means  "to  unambiguously 
describe  requirements  and  systems  themselves  in  terms  of  behavior  and  structure."  (Hal 
Carter,  "Computer-Aided  Design  of  Integrated  Circuits")  As  a  design  language,  it  allows 
effective  communication  between  a  designer  and  a  design  tool.  As  a  description  language, 
it  allows  effective  communication  among  design  environments,  both  inter-  and  intra¬ 
company.  (Ron  Waxman,  "The  Many  Faces  of  Electronic  Computer-Aided  Design") 
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PDES  is  a  long-range  concept.  As  of  this  writing,  it  is  a  volunteer  research  and 
development  activity  under  the  purview  of  the  NBS  IGES  organization.  Some  believe  it  is 
also  a  standardization  activity.  The  objective  of  this  concept  is  to  develop  a  neutral 
exchange  capability  for  all  product  data  between  CAD/CAE/CAM/CAI  systems.  This 
capability  has  not  been  well-defined,  but  will  probably  consist  of  two  components:  "an 
information  model  which  defines  and  explains  how  the  data  elements  transmitted  are  to  be 
interpreted  and  used... and  the  exchange  format  specification  itself."  (W.  C.  Burkett, 
"Good,  Fast,  Cheap")  The  prevailing  goal  of  this  project  is  to  produce  a  representation  of 
product  data  with  adequate  explicit  meaning  to  allow  complete  interpretation  of  the  data  by 
the  design  system.  In  other  words,  "the  results  of  this  work  will  be  a  roadmap  for  building 
exchange  standards  which  are  easy  to  implement,  precise,  less  ambiguous,  and  easily 
testable."  (ML  Brei,  "CAE  Standards  Coordination  Meeting  Report") 

All  of  the  standards  covered  in  this  study  share  the  following  characteristics: 

( 1 )  the  scope  broadens  as  the  format  matures 

(2)  all  were  designed  to  be  neutral,  non-proprietary  standards 

(3)  all  represent  some  form  of  product  data 

The  basic  differences  of  these  standards  include: 

( 1 )  some  require  interpretation 

(2)  others  are  directly  processable  by  design  automation  tests.  Each  was  designed 
with  a  distinct  application  in  mind. 

B.  HISTORY 

It  is  important  to  have  a  basic  understanding  of  the  history  of  the  standards 
development  organizations.  Knowledge  of  the  forces  driving  the  development  of  the 
formats,  how  the  organizations  were  formed,  and  who  was  involved  in  the  initial  design 
activities  provide  insights  into  the  nature  of  the  format  and  future  viability. 

In  1967,  the  IPC  formed  a  committee  to  "establish  a  digital  language  for  describing 
the  characteristics  of  a  printed  wiring  board"  (Bergman,  "Long  Range  Plan  for  an  Electrical 
Computer  Format  Standardization  Effort")  as  a  replacement  for  the  master  drawing.  This 
was  in  response  to  a  need  expressed  by  military  contractors.  The  first  draft,  D-350,  was 
approved  in  1972.  Revision  A  of  D-350  was  released  in  February  1975  and  approved  as 
an  ANSI  standard  in  May  1975.  Over  20  principle  contributors  were  involved  in  the 
development  and  subsequent  enhancements  of  this  specification.  The  committee  developed 
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supplemental  specifications  (351,  352,  353,  and  354)  to  handle  additional  data  requested 
by  government  representatives  without  breaking  a  commitment  to  freeze  D-350  for  five 
years.  The  current  draft  of  D-350  is  Revision  C,  released  in  July  1986.  Both  D-351  and 
D-352  were  adopted  in  September  1985  and  approved  for  use  by  DoD.  The  specifications 
D-353  and  D-354  were  released  in  draft  form  in  1986.  The  subcommittee  on  "IPC-D-350 
Development,"  under  the  Committee  on  Computer-Aided  Technology  (CAT),  is  currently 
responsible  for  the  development  and  maintenance  of  the  D-35x  specifications. 

The  IGES  organization  was  founded  at  a  meeting  held  on  October  11,  1979,  in 
response  to  a  recommendation  made  by  the  DoD  Manufacturing  Technology  Advisory 
Group.  The  meeting  was  convened  by  the  Air  Force,  Army,  Navy,  NASA,  and  NBS  at 
the  National  Academy  of  Sciences  to  discuss  data  exchange  problems.  The  original 
Technical  Committee,  a  small  group  from  Boeing,  General  Electric,  and  the  National 
Bureau  of  Standards,  was  formed  at  this  meeting.  The  Technical  Committee  borrowed 
heavily  from  two  projects:  the  Boeing  CAD/CAM  Integrated  Information  Network  (CIIN) 
format  and  the  General  Electric  Neutral  Database  project.  Three  months  after  the  formation 
of  the  Technical  Committee  (January  1980),  the  first  version  of  IGES  was  published  by  the 
National  Bureau  of  Standards.  In  September  1981  it  was  approved  as  an  ANSI  standard 
by  the  ASME  Committee  Y14.26.  After  the  publication  of  the  first  version,  additional 
committees  were  formed  and  the  IGES  organization  took  shape.  IGES  3.0  is  in  the  final 
stages  of  approval  by  Y14.26  as  an  ANSI  standard. 

The  IGES  Electrical  Applications  Committee  (EAC)  was  formed  in  January  1983. 
The  purpose  of  the  EAC  was  to  recommend  format  extensions  to  handle  integrated  circuit 
applications  (the  design,  engineering,  manufacturing,  and  testing  of  both  individual  parts 
and  the  packaging  of  parts  into  a  product).  After  creating  an  IDEFl-x  data  model  of 
electrical  connectivity,  the  EAC  developed  a  physical  implementation  and  presented  it  to  the 
general  assembly.  These  enhancements  were  accepted  and  incorporated  in  IGES  version 
3.0.  (IGES  3.0,  Electrical  Application  Guide ) 

The  EDIF  organization  was  formed  in  November  1983  as  the  result  of  general 
dissatisfaction  with  existing  formats  for  IC  design  data.  The  founders  of  EDIF  were  from 
Texas  Instruments,  National  Semiconductor,  Motorola,  the  University  of  California  at 
Berkeley,  Tektronix,  Daisy  Systems,  and  Mentor  Graphics.  The  founders  had  contributed 
toward  the  development  of  previous  exchange  formats  and  decided  to  leverage  as  much 
knowledge  and  experience  as  possible  from  those  activities.  Consequently,  EDIF  was 
based  on  concepts  from  CIDL  (Common  Interchange  Description  Language),  GAIL 
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(Daisy's  Gate  Array  Interface  Language,  TDF  (Motorola's  Technology  Description  File), 
and  TIDAL  (Texas  Instruments'  Transportable  Integrated  Design  Automation  Language). 
The  founders  identified  four  general  problems  with  the  existing  formats.  Each: 

(1)  addresses  a  narrow  focus, 

(2)  is  proprietary, 

(3)  is  difficult  to  implement,  and 

(4)  is  difficult  to  extend. 

An  initial  draft  version,  0.8,  was  completed  in  March  1984.  Subsequent  versions  (1.0  in 
March  1985;  1.10  in  November  1985)  have  led  to  the  release  of  the  current  version,  2.0,  in 
July  1987.  Version  2.0  is  published  by  the  Electronics  Industries  Association  as  an  Interim 
Specification. 

The  Air  Force  Very  High  Speed  Integrated  Circuit  (VHSIC)  Program  Office 
developed  VHDL  in  response  to  a  "need  for  a  standard  means  of  communication  to 
streamline  advanced  digital  design  and  documentation."  (Dewey  and  Gadient,  "VHDL 
Motivation")  A  team  from  Intermetrics,  IBM,  and  Texas  Instruments  was  formed  to 
identify  language  requirements  and  to  develop  the  language  (from  1981  to  1983).  This 
effort  was  directed  by  a  VHDL  Tri-Service  Committee.  After  developing  requirements  for 
the  language,  the  team  was  responsible  for  developing  the  language,  providing  a  support 
environment,  and  providing  software  tools  (a  compiler,  a  reverse  analyzer,  a  simplifier, 
and  a  simulator).  The  program  was  organized  in  four  teams:  the  Requirements  Analysis 
Team,  the  Definition  Team,  the  Review  Team,  and  the  Scenarios  and  Benchmark  Team.  A 
draft  of  the  VHDL  was  presented  to  potential  users  in  February  1984.  After  revisions  were 
made  by  an  IEEE  VHDL  Analysis  and  Standardization  Group  (VASG),  Draft  1076/B  was 
approved  by  ballot  in  July  1987.  The  final  approval  from  IEEE  was  established  in 
December  1987.  The  programming  language,  Ada,  had  a  significant  impact  on  the 
language  design,  intermediate  form,  and  support  environment  architecture.  The  VHDL 
iMnguage  Requirements  document  states  "where  the  semantics  of  a  VHDL  construct  match 
the  semantics  of  an  Ada  construct  then  Ada  syntax  should  be  used."  (pp.  5-6) 

After  recognizing  that  a  non-upward  compatible  format  was  necessary  to  address 
the  inherent  problems  limiting  IGES,  members  of  the  IGES  organization  initiated  the  PDES 
Project.  In  April  1984,  an  ad  hoc  subcommittee  was  chartered  to  examine  issues  for  an 
upcoming  version  of  IGES.  The  committee  recommended  the  development  of  a  non- 
upward  compatible  version  of  IGES.  In  November  1984,  the  Ad  Hoc  Committee  released 
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a  report  suggesting  content  and  development  methodology  for  the  new  format.  The 
development  methodology  was  based  on  a  three-layer  architecture  (similar  but  not  identical 
to  database  architectures),  reference  models  (for  each  application),  format  definition 
languages,  and  a  minimally  redundant  entity  set. 

A  PDES  proof-of-concept  effort,  the  Initiation  Activities,  began  in  early  1985.  This 
activity  concentrated  on  validating  the  concepts  and  proposed  methodology.  It  resulted  in 
A  Reporting  of  the  Initiation  Activities,  released  in  May  1986,  containing  a  "Plan  for  PDES 
Version  1.0,"  "Logical  Layer  Committee  Report,"  "Physical  File  Structure  Task  Report," 
critiques,  minority  reports,  and  technical  appendices.  After  the  release  of  the  Reporting  of 
the  Initiation  Activities,  PDES  subcommittees  continued  working  on  reference  models,  the 
physical  file  structure,  and  other  related  projects.  The  work  accomplished  during  this 
period  can  L»est  be  characterized  as  intense,  yet  unfocused.  The  PDES  Testing  Draft, 
released  in  February  1987,  is  evidence  of  the  lack  of  a  well-defined  PDES  strategy.  The 
PDES  Testing  Draft  consists  of  a  set  of  four  integrated  reference  models  in  the  Express 
language.  It  is  up  to  the  reader  of  the  document  to  determine  what  to  do  with  the  integrated 
model.  Many  problems  with  the  organization  of  the  PDES  volunteer  project  have  become 
apparent  to  both  observers  and  participants  of  the  effort,  and  the  project  is  currently 
undergoing  a  major  reorganization.  A  PDES  Industry  Cooperative  (  PDES,  Inc.)  is  being 
organized  to  lead  an  accelerated  development  of  PDES.  This  effort  is  being  driven  by  the 
DoD  CALS  OSD  Policy  Office.  The  relationship  between  the  volunteer  effort,  PDES, 
Inc.,  and  other  competing  efforts  is  as  of  yet  undetermined. 

The  timeline  in  Figure  II- 1  provides  a  reference  for  tracking  the  histories  of  the 
development  of  each  of  these  standards.  EPC-D-35x  has  been  evolving  for  about  20  years. 
PDES,  at  the  other  extreme,  is  a  three-year  old  effort.  Similarities  among  the  development 
efforts  not  recorded  in  the  timeline  include: 

( 1 )  All  sought  extensive  public  comment/review 

(2)  All  have  been  or  are  in  the  process  of  being  approved  by  a  standardization 
body. 
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Figure  11-1.  Timeline  of  CAE  Standards  Organizations  Milestones 


I 

Ip  Differences  include: 

( 1 )  All  but  IPC  were  clearly  leveraged  from  existing  formats 

£  (2)  IGES,  VHDL,  and  PDES  were  led  by  government  agencies,  whereas  EDIF 

was  initiated  by  an  ad  hoc  industry  consortium,  and  EPC-D-35x  was  a 
£  response  to  user  needs. 

The  chart  in  Table  II-2  summarizes  the  formation  activities  of  the  standards  development 
■  groups. 


Table  11-2.  The  Formation  of  the  Development  Groups 


IPC-D-35X 

IGES 

EDIF 

VHDL 

PDES 

Kickoff 

1967  IPC 

Committee 

established 

October  1 979 
at  National 
Academy  of 
Science  Meeting 

November  1983 
Arizona 

1981  Woods  Hole, 
MA  Workshop 

November  1 984 

Founders 

IPC  Committee 

Boeing,  NBS, 

G.E.  in  response 
to  DoD  Mantech 
Advisory  Group 

Motorola,  T.I., 
Daisy,  Mentor, 
National  Semi¬ 
conductor, 
Tektronics,  UC 
at  Berkeley 

USAF  VHSIC 
Program; 
Contractors 
intermetrics, 

IBM,  T.l. 

IGES  ad  hoc 
Committee 

Precursors 

? 

Boeing  CNN 

G.E.  Neutral 
Database 

CIDF,  GAIL, 

TDF,  TIDAL 

Ada  and  existing 
HDLs 

IGES,  SET, 
PDDI,  VDAFS, 
CAD*I 

C.  DESIGN  GOALS 

All  of  these  development  efforts  have  been  guided  by  a  set  of  goals  and/or 
guidelines.  Some  of  these  guidelines  have  been  documented  in  project  reports,  others  have 
been  implied  in  articles  written  by  principle  contributors  to  the  projects.  These  guidelines 
are  outlined  in  this  section. 

IPC-D-35x  Series 

Early  requirements  (implied): 

(1)  The  format  must  allow  manual  preparation  of  the  data  as  well  as  CAD 
preparation. 

(2)  Establish  a  generic  format  "transparent  to  the  various  numerical  control 
machines  used  in  the  development  of  artwork  tooling,  or  for  drilling  and 
routing  printed  boards."  ("Report  of  IPC  Electronic  Design  Data  Description 
Seminar,"  October  1985) 
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Development  guidelines  (implied): 

(1)  Maintain  similarity  among  the  D-35x  series  (modularity). 

(2)  Handle  complete  and  partial  design  data. 

Goals  of  the  initial  effort: 

(1)  Publish  something  by  early  1980. 

(2)  Completeness:  enable  complete  data  exchange  among  computer-based  drafting 
systems. 

(3)  Extensibility:  allow  for  extensions  to  the  format. 

(4)  Processor  compatibility:  allow  for  the  use  of  existing  translation  techniques  to 
process  the  format. 

(5)  Obtain  and  incorporate  as  much  input  as  possible  from  the  user  community. 
Principles  guiding  the  ongoing  development: 

( 1 )  Maintain  upward  compatibility. 

(2)  Ensure  non-redundant  entity  sets  (define  an  entity  in  one  way). 

(3)  "Serve  as  a  common  format  to  drive  internal  manufacturing  cycle,  and  external 
customers/vendors/suppliers." 

(4,.  "In  place,  functioning,  and  usable  (not  blue  sky)."  ( IGES  Electrical 
Application  Guide ) 

EfilE 

( 1 )  Produce  a  standard  within  five  years. 

(2)  Minimize  talk,  maximize  work. 

(3)  Keep  the  syntax  simple,  consistent,  unambiguous,  and  extensible. 

(4)  Maintain  upward  compatibility  between  releases. 

(5)  Do  not  make  it  a  design  language. 

(6)  EDIF  will  become  a  standard  by  use,  not  by  edict. 

(7)  Keep  the  standard  neutral  and  in  the  public  domain. 

(8)  Handle  partial  and  complete  design  data. 
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YHPL 

Global  contract  objectives: 

(1)  "The  VHDL  shall  be  capable  of  fully  documenting  digital  hardware... ranging 
from  entire  systems  to  logical  gates." 

(2)  "...the  VHDL  will  be  used  as  a  design  and  documentation  tool." 

(3)  "...the  complexity  of  the  language  must  be  controlled...." 

Design  objectives  (M.  Shahdad,  "An  Overview  of  VHDL  Language  and 
Technology"): 

(4)  Semantic  precision 

(5)  Methodology  independence 

(6)  Hierarchical  description 

(7)  Support  for  digital  modeling  techniques 

(8)  Support  for  approaches  to  timing 

(9)  Support  for  hardware  technologies 

(10)  Support  for  styles  of  description 

(11)  Support  for  design  automation  tools. 

EP.ES 

Objectives  defined  by  the  Ad  Hoc  Committee: 

( 1 )  Support  both  state-of-the-art  and  leading  edge  CAD/CAM  environments. 

(2)  Provide  a  clear  and  unambiguous  specification. 

(3)  Ensure  the  standard  can  be  and  is  implemented. 

(4)  Minimize  the  cost  of  building  and  using  PDES  processors. 

(5)  Ensure  that  the  transfer  process  is  reliable  and  predictable. 

(6)  Provide  migration  path  from  IGES  to  PDES. 

A  few  of  the  requirements: 

( 1 )  Minimize  file  size  and  processing  time. 

(2)  Accommodate  functional  capabilities  of  IGES  3.0. 

(3)  Provide  complete  representation  of  product  data. 

(4)  Exchange  and  archive  data  in  a  computer  recognizable  form. 

(P.  Wilson,  "A  View  of  PDES") 
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Common  development  activity  criteria  includes: 

(1)  extensibility, 

(2)  upward  compatibility, 

(3)  machine  processable  systems, 

(4)  human  readable  systems, 

(5)  neutral,  and 

(6)  public  domain. 

These  goals  are  very  important;  they  flavor  the  evolution  of  the  formats  and  have  a 
tremendous  impact  on  the  success  of  the  formats  (both  technically  and  politically).  The 
extensibility  design  criterion  ensures  that  mechanisms  for  expanding  the  format  are  in  place 
to  keep  pace  with  technology  advances.  The  upward-compatibility  design  criterion  ensures 
that  investments  made  in  early  versions  of  the  format  will  not  be  lost.  The  machine- 
processable  syntax  design  criterion  ensures  that  writing  translators  to  read  and  write  the 
format  will  not  require  excessive  effort.  The  human  readable  syntax  criterion  ensures  that 
the  data  will  always  be  accessible  to  human  beings  without  computerized  tools.  The 
neutrality  design  criterion  ensures  that  the  standard  is  applicable  for  any  appropriate  tool 
and  design  environment.  Finally,  the  public  domain  design  criterion  ensures  the  non¬ 
proprietary  nature  of  the  format. 

D.  APPLICATION  AREAS 

Table  II-3  illustrates  the  application  areas  for  which  the  standards  are  designed  to  be 

used. 

E.  INFORMATION  COVERAGE 

The  following  lists  of  information  covered  by  each  of  the  standards  were  composed 
after  reviewing  technical  documents  and  other  literature.  The  lists  are  generalized.  The 
terms  are  not  necessarily  consistent  among  the  formats.  For  example,  an  EDIF  schematic 
is  different  from  an  IPC-D-35x  schematic.  It  is  impossible  at  this  point  to  establish 
consistent  lists  because  industry-accepted  (standard)  definitions  of  the  information  required 
and  generated  by  CAE/CAD  systems  do  not  exist.  A  comprehensive  comparison  of  the 
information  coverage  of  these  formats  is  impossible  until  such  an  information  model  is 
developed  and  accepted  by  the  CAE/CAD  industry. 
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Table  11-3.  Application  Areas 


IPC-D-35X 

IGES 

EDI  F 

ELECTRICAL 

IC  Design 

X 

IC  Testing 

X 

IC  Manufacturing 

X 

Printed  Board  Design 

X 

X 

X 

Printed  Board  Testing 

X 

X 

X 

Printed  Board  Manufacturing 
System  Level  Design 

System  Level  Testing 

System  Level  Manufacturing 

X 

X 

X 

ELECTRICAL/MECHANICAL 

Component  Design 

X 

Component  Manufacture 

X 

MECHANICAL 

Part  Design 

X 

Part  Analysis 

X 

FEM 

X 

Solids  Modeling 

X 

Part  Manufacturing 

X 

ARCHITECTURAL 

Distribution  Systems 

X 

OTHER  DRAFTING 

X 

IPC-D-351-352.  353,  354,_J55 

PCB  artwork 

PCB  Board  descriptions 

Schematics 

Master  drawings 

Assembly  drawings 

Part  drawings 

Netlists 

Parts  definitions 
Design  rules 
Test  data 

Library  information 
Mechanical  tooling 

IGES  3,0 


Netlist 

IC  symbolic  layout 
PCB  layout 


Schematics 

Mechanical  drawings  (2-  and  3-D  wireframe) 

Mechanical  tooling 
Photoplot 
Process  flowsheets 
Finite  element  models 
Tabular  data 

EDIF  2J) 

Netlist 

IC  symbolic  layout 
PCB  layout 
Schematic 
Simulation  models 
Timing  information 
Test  patterns 
Documentation 
Hierarchical  structure 
Physical  design  rules 

VHPL  1076/B 

Behavioral  description 
Architectural  description 
Structural  descriptions  (hierarchical) 

Timing  data 
Environmental  data 

Physical  attribute  data  (placement,  timing,  power) 

Schematic  data  (no  semantics) 

Layout  data  (no  semantics) 

According  to  these  lists,  the  IPC-D-35x  series  and  IGES  appear  to  handle  very 
similar  data.  The  critical  difference  between  IGES  data  and  IPC-D-35x  data  is  that  IGES 
data  basically  consists  of  geometrical  primitives  which  require  interpretation,  whereas  IPC- 
D-35x  data  consists  of  functional  primitives  oriented  toward  the  end-product,  the  printed 
circuit  board. 

The  same  difference  exists  between  EDIF  and  IGES  and  between  VHDL  and  EDIF 
with  respect  to  schematic  and  layout  data.  In  addition  to  the  powerful  constructs  to 
describe  behavior,  VHDL  provides  some  constructs  for  describing  geometry.  The  meaning 
of  the  geometry,  however,  must  be  interpreted  by  the  tools  which  process  the  data.  The 
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constructs  for  this  information  in  EDIF,  however,  are  functional  primitives  oriented  toward 
IC  and  PCB  layout  concepts. 

The  EDIF  organization  does  not  plan  to  incorporate  all  aspects  of  design.  In 
particular,  it  will  not  represent  3-D  mechanical  drawings  and  analyses,  nor  will  it  represent 
system  manufacturing  level  information  and  other  system  design  language  functions. 

F.  FUNDING  SOURCES 

The  IPC-D-35x  series  are  developed  and  supported  by  representatives  from  IPC 
member  companies.  EPC  is  a  non-profit  trade  association  with  about  1,400  member 
companies,  many  of  which  are  aerospace  companies.  The  purpose  of  IPC  is  to  develop 
standards  and  technical  documentation  for  the  electronic  packaging  industry. 

IGES  is  a  project  of  the  Air  Force  Integrated  Computer-Aided  Manufacturing 
(ICAM)  Program.  Funds  are  provided  to  the  National  Bureau  of  Standards  by  the  Air 
Force,  Army,  Navy,  and  NASA.  The  funds  are  used  to  manage  the  IGES  organization. 

EDIF  does  not  have  an  official  funding  source  other  than  the  ad  hoc  consortium  of 
founding  companies  which  form  the  Steering  Committee. 

VHDL  is  a  project  of  the  Air  Force  VHSIC  Program.  A  contract  was  awarded  to  a 
team  from  Intermetrics,  IBM,  and  Texas  Instruments  for  the  initial  development  of  the 
language.  Subsequent  funds  were  provided  to  CAD  Language  Systems,  Inc.  (CLSI)  for 
administrative  support  of  the  IEEE/DASS  standardization  process,  and  to  develop 
additional  documentation.  Documents  and  training  are  available  from  CLSI.  Funds  have 
been  provided  to  various  organizations  for  verification  and  validation  support  (the  National 
Bureau  of  Standards,  the  United  Technologies  Microelectronics  Center,  and  Digital 
Equipment  Corporation. 

PDES  is  an  IGES  project  and  receives  funds  accordingly.  If  PDES,  Inc.,  is 
successful,  then  funding  and  manpower  will  be  supplied  by  the  15-20  member  companies 
of  the  Cooperative.  The  PDES  Cooperative  will  be  administered  through  a  "host” 
contractor.  Potential  candidates  for  this  task  include  Computer-Aided  Manufacturing 
International  (CAM-I),  the  South  Carolina  Research  Authority  (SCRA),  Battelle,  and  the 
Institute  for  Manufacturing  and  Automation  Research  (IMAR).  ("Draft  Prospectus  for  an 
Industry /Government  PDES  Cooperative  Project") 
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G.  INDUSTRY  SUPPORT 

This  section  describes  who  is  supporting  the  standards  and  the  extent  of  that 
support.  In  many  cases,  it  is  difficult  to  assess  the  strength  of  the  support  claimed  by  the 
organizations.  The  chart  in  Table  II-4  summarizes  the  international  support,  Department  of 
Defense  support,  and  the  funding  sources  for  each  of  the  standards. 


Table  11-4.  SUPPORT 


IPC-D-350 

IGES 

EDIF 

VHDL 

PDES 

International 

Support 

European 

Member 

Companies 

Limited  due  to 
competition 
with  the  French 
SET  and  West 
German  VDAFS 

Extensive 

User  Groups 
in  Britain,  West 
Germany,  and 
Japan 

Hindered  by 
ITAR;  Projects 
underway  in 
Sweden, 
Canada,  and 
England 

ISO/STEP 

TC  184SC4 
(members  in¬ 
clude  Belgium, 
France,  Canada, 
Japan,  Poland, 
US,  and  West 
Germany 

DoD  Support 

Strong  in 

Isolated  Cases 
(NS  A) 

Strong 

Pending:  DoD 
CALS  Policy 
Office  has 
expressed 
interest 

Strong 

Strong 

Funding  Source 

IRC  Member 
Companies 

USAF ICAM 
program  funds 
provided  by  AF, 
Army,  Navy, 
and  NASA 

Founding 

Companies; 

El  A  Member 

Companies 

(Pending) 

USAF  VHSIC 
Program 

Industry 

Cooperative 

(Pending) 

The  IPC-D-350  specifications  are  developed  and  supported  by  representatives  from 
member  companies,  both  U.S.  and  European.  The  principle  user  and  force  behind 
enhancements  to  the  formats  is  the  National  Security  Agency.  These  formats  are  more 
mature  than  the  others  covered  in  this  report.  Vendor  implementations  include  Calay, 
Cadnetix,  and  Racal  Redac.  Current  plans  are  to  increase  vendor  support  of  the 
specifications.  Although  the  specifications  have  been  required  on  government  contracts, 
printed  board  CAD  vendors  are  not  anticipating  a  large  demand  for  the  formats.  Large 
aerospace  companies,  however,  may  request  IPC-D-350  implementations  in  the  near 
future.  A  user  group  was  formed  in  1986  to  bring  industry  people  together  to  discuss 
implementation,  software,  test  and  verification  issues  and  vendor  plans  for  support 
(William  Lange,  "IPC-350  Specifications") 

The  IGES  organization  is  a  voluntary  body  of  representatives  from  the  user 
community  (for  the  most  part)  and  the  CAD  community.  The  user  community  includes: 
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McDonnell  Douglas,  Boeing,  Hughes,  General  Dynamics,  Lockheed, 
Rockwell,  Allied  Bendix,  LTV  Aerospace,  Northrop,  Ford  Aerospace; 


automotive  companies: 

Ford  Motor,  GM,  BMW; 
equipment  manufacturers: 

IBM,  DEC,  Caterpillar,  Westinghouse,  Eastman  Kodak,  Hewlett  Packard; 
national  laboratories: 

Sandia,  Lawrence  Livermore; 
academia: 

MIT,  California  State  University,  University  of  Michigan,  Duke;  and  the 
military  services. 

Members  from  CAD  vendors  include  Computervision,  Applicon,  Tektronix,  Daisy, 
Ontologic,  Scientific  Calculations,  Cadnetix,  Calma,  Intergraph,  and  Cognition.  Most 
major  CAD/CAM  companies  support  some  level  of  IGES.  In  a  1987  survey  by  CAD/CIM 
about  35  vendors  reported  some  support  for  subsets  of  IGES  entities.  Only  two  vendors 
(CALMA  and  Summa  Graphics)  claimed  to  support  the  electrical  entitites.  Most  of  those 
surveyed  support  the  geometric  entities.  None  of  the  vendors  claimed  to  support  all  IGES 
entities.  As  of  spring  1987,  there  were  628  members  listed  on  the  general  membership 
roster  and  about  40  members  on  the  Steering  Committee.  Of  the  628  members,  8  percent 
are  foreign,  26  percent  are  vendors,  and  2  percent  are  from  academia.  Over  260  companies 
are  represented.  The  number  of  attendees  at  quarterly  meetings  range  from  200  to  250. 
European  support  for  IGES  has  been  severely  hindered  by  the  French  acceptance  of  SET  (a 
streamlined  version  IGES)  and  the  German  acceptance  of  VDAFS  (another  derivative  of 
IGES). 

The  EDIF  organization  is  composed  of  volunteers  from  the 
CAE/CAD  vendor  community: 

Daisy,  Mentor,  Valid,  Tektronix,  Cadnetix,  Viewlogic,  Racal  Redac,  Calma, 

Computervision,  SDA  Systems,  Futurenet,  Xerox,  and  Hewlett  Packard; 


Motorola,  National  Semiconductor,  Intel,  Texas  Instruments,  and  AT&T  Bell 
Laboratories,  IBM;  and 


the  University  of  California  at  Berkeley,  the  University  of  Arizona,  the 
University  of  Manchester,  and  the  University  of  Waterloo. 

Several  EDIF  user  groups  have  been  formed  in  the  last  year  (in  the  United  States, 
Britain,  West  Germany,  and  Japan).  Approximately  200  people  attend  the  general  user 
group  meetings  held  at  the  ICCAD  conferences  in  the  fall  and  the  Design  Automation 
Conferences  held  in  the  spring.  Over  2,000  names  are  on  the  EDIF  mailing  list,  500  of 
which  are  from  Europe  or  Japan.  There  are  currently  1 1  U.S.  technical  subcommittees 
with  active  memberships  ranging  from  6  to  20  people.  DoD  is  beginning  to  show  interest 
in  the  format.  The  OSD  CALS  Policy  Office  is  considering  the  inclusion  of  EDIF  in  the 
Core  Requirements  Specifications. 

A  number  of  trial  implementations  of  subsets  of  EDIF  have  been  available  since  the 
release  of  version  1.0.  At  the  release  of  Version  2.0,  at  least  a  dozen  vendors  committed  to 
the  development  of  EDEF-based  products,  and  another  dozen  vendors  expressed  interest 
pending  customer  demand.  The  first  2.0-based  products  will  probably  be  EDIF  netlist  and 
schematic  interfaces.  These  should  appear  within  6  months  to  2  years. 

Non-U. S.  support  for  EDIF  is  growing  rapidly.  In  1985,  the  United  Kingdom 
CAE  Consortium  "concluded  that  the  EDIF  format  met  its  requirements  and  that  it  would 
therefore  be  better  to  work  with  the  U.S.  and  the  rest  of  Europe  to  support  EDIF  than  to 
develop  its  own  language."  ("European  IC  Designers  Vote  for  EDIF  Standard")  Britain's 
Alvey  Fifth-generation  computer  project  has  also  demonstrated  strong  support  and  has  made 
significant  contributions  to  the  development  of  the  format  by  funding  the  development  of 
information  models,  translators  and  other  software  utilities,  and  trial  transfers.  There  are 
several  European  technical  subcommittees  which  make  recommendations  to  the  U.S. 
organization.  British,  West  German,  and  Japanese  User  Groups  have  also  formed.  Japan 
has  recently  formalized  an  interest  in  EDIF.  "Fujitsu  and  Hitachi  foundries  are  publishing 
requirements  for  future  design  information  to  be  presented  in  EDIF  formats."  (Henry 
Alward,  "Latest  EDIF  Version  Marks  a  Milestone  for  CAE/CAD") 
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The  support  for  VHDL  has  been  driven  by  the  development  effort,  the 
standardization  process,  and  demonstration  programs  funded  by  the  Air  Force.  According 
to  John  Hines  (Appendix  L), 

CAE/CAD  companies: 

ENDOT,  Daisy,  Hewlett  Packard,  Mentor,  Silvar-Lisco,  CLSI,  Intermetrics; 

equipment  and  machine  manufacturers: 

General  Dynamics,  Boeing,  Sperry,  IBM,  Honeywell,  Gould,  Unisys,  TRW; 

and 

universities  and  research  organizations: 

Stanford,  Virginia  Tech,  Renssellaer  Polytech,  Dartmouth,  JRS  Research, 

Research  Triangle  Institute,  and  Arizona  State  University 

participated  in  the  development  effort.  The  activities  of  the  EEEE/Design  Automation 
Standards  Subcommittee  have  also  generated  strong  interest  within  the  design  community. 
The  VHDL  mailing  list  contains  about  200  names.  An  informal  VHDL  Users  Group  has 
been  meeting  at  VPI.  VHDL  workshops  and  training  classes  are  being  offered  on  a  regular 
basis  to  generate  interest  and  expertise  in  VHDL. 

Moe  Shahdad  in  "An  Overview  of  VHDL  Language  and  Terminology"  (July  1986) 
reports  on  the  following  activities  which  involve  VHDL:  the  IBM/VHDL  environment, 
Sperry  Corporations'  VHDL  interface  to  the  MIXSIM  simulator,  a  bi-directional  translator 
between  VHDL  and  HHDL  by  Silvar-Lisco,  design  capture  tools  by  Gould  Research 
Center,  a  VHDL-ADAS  interface  by  Research  Triangle  Institute  (RTI),  a  silicon  compiler 
by  RTI,  Silicon  Compilers,  and  E-Systems,  a  microcode  simulation  system  by  JRS 
Research  Laboratories,  the  MIMOLA  Software  System  by  Honeywell,  and  the  Tester 
Independent  Software  Support  System  (TISSS)  by  Harris. 

International  Traffic  in  Arms  Regulations  (ITAR)  which  covered  the  VHSIC 
program  prohibited  non-U. S.  participation  in  the  initial  design  of  VHDL.  Documentation 
was  not  available  outside  the  VHSIC  community.  Although  ITAR  restrictions  were  lifted 
two  years  ago,  this  will  have  a  major  impact  on  whether  or  not  VHDL  will  be  accepted  as 
an  International  Standard.  (Dr.  T.  L.  Throp,  in  a  letter  to  R.  Waxman,  March  1986)  Some 
proponents  of  VHDL  have  reported  that  the  European  design  automation  community  is 
expressing  much  interest  in  VHDL,  especially  in  France.  Specific  international  programs 
are  occurring  in  Sweden  (NMP-CAD  adopted  VHDL  as  a  basis  for  design  description). 


31 


Canada  (BNR  is  retesting  a  VHDL  interface  on  the  IBM),  and  England  (Plessey  is  creating 
a  VHDL  interface  to  their  workstations). 

The  contributors  to  the  PDES  project  are  members  of  the  IGES  organization.  The 
anticipated  user  community  of  PDES  will  be  predominantly  from  the  aerospace  and  defense 
industries.  DoD  (the  CALS  program  and  advanced  weapon  systems  programs)  and  the 
International  Standards  Organization  (ISO)  Standard  for  the  Exchange  of  Product  Data 
(STEP)  project  are  also  promoting  and  contributing  to  PDES.  Specific  programs  which  are 
depending  on  PDES  include:  CALS,  the  AFLC  CAD/CAM  Integration  PIM,  the  USAF 
ATF,  and  the  Navy  CAD  II  CAD/CAM  procurement.  PDES  is  not  ready  for 
implementation  at  this  time.  I  do  not  know  of  any  complete  PDES  proof-of-concept 
demonstrations  with  the  exception  of  the  Initiation  Activities  (see  above). 

H .  FILE  FORMAT 

The  IPC-D-35x  formats  are  static  data  structures  based  on  an  80-column  card  image 
ASCII  format  with  specific  field-oriented  records.  Reserved  words,  letters,  and  codes 
provide  meaning. 

Designs  are  organized  in  job  sets.  Within  a  job  set,  data  is  structured  in  data 
information  modules.  Types  of  data  information  modules  include  electrical  description, 
artwork,  boards,  schematic,  master  drawing,  assembly  drawing,  etc. 

Discrete  units  of  information  are  stored  in  individual  files.  For  instance,  there  may 
be  a  file  for  plated-through  holes,  for  lands,  for  conductor  patterns,  etc. 

IGES  is  a  static  file  structure  based  on  an  80-column  record  format.  The  data  is 
numerically  coded  in  fixed  and  free  format  lines.  The  file  can  be  formatted  according  to 
ASCII,  compressed  ASCII,  or  binary  specifications. 

IGES  files  contain  basic  information  units  called  entities.  Entities  can  be  either 
geometric  or  non-geo  metric.  Non-geometric  entities  provide  annotation,  dimensioning, 
attribute,  and  grouping  capabilities.  Entities  are  organized  in  five  or  six  sections:  Flag, 
Start,  Global,  Directory,  Entry,  Parameter  Data,  and  Terminate.  Relationships  can  be 
established  among  entities,  meanings  can  be  assigned  to  relationships,  and  specific 
characteristics  can  be  assigned  to  entities. 

Changes  to  IGES  involve  modifications  of  existing  entity  structures,  the 
introduction  of  new  entity  structures,  and/or  the  obsolescence  of  entities. 


32 


EDIF  is  a  non-executable,  ASCII  data  format  patterned  after  LISP.  Data  in  EDIF 
files  are  organized  hierarchically  in  the  form  of  EDIF  statements.  EDIF  statements  are 
parenthesized  lists  identified  with  a  keyword.  The  semantics  are  based  on  keyword 
definitions.  The  keywords  are  defined  in  the  EDIF  specification. 

The  basic  design  unit  in  EDIF  is  called  a  cell.  A  cell  can  have  one  or  more 
representations  or  views.  Each  view  contains  a  particular  perspective  of  the  design.  For 
instance,  the  electrical  connectivity  of  a  circuit  is  established  in  the  Netlist  view.  Other 
views  include  Behavior,  Document,  Graphic,  LogicModel,  Masklayout,  Netlist, 
PCBLayout,  Schematic,  Stranger,  and  Symbolic. 

Extensions  to  EDIF  are  made  by  defining  new  keywords.  The  EDIF  Technical 
Committee  has  established  a  set  of  general  rules  for  extending  EDIF  in  the  future  to  ensure 
upward  compatibility. 

VHDL  is  a  hierarchical  design  language  patterned  closely  after  Ada.  It  has  a 
context-free  syntax  and  uses  a  subset  of  the  ASCII  character  set.  Its  semantics  are 
keyword-driven.  Both  static  and  dynamic  semantics  are  defined  in  the  VHDL  Language 
Reference  Manual.  The  language  provides  procedural  (sequential  processing),  concurrent, 
or  a  combination  of  the  two  (block-oriented)  sequencing  mechanisms. 

Abstractions  of  real  hardware  are  represented  as  design  entities  in  VHDL.  Design 
entities  provide  the  means  for  modeling  transforms  (via  input  and  output  ports,  signals,  and 
functions).  Each  design  entity  has  an  interface  description  (input/output  declarations  and 
attribute  definitions)  and  one  or  more  body  descriptions.  "The  body. ..describes  the 
internal  operation  or  organization  of  the  component  being  described.  The  internal  details  of 
the  component  may  be  described  using  structural,  data-flow,  or  procedural  styles  of 
expression."  (M.  Shahdad,  "An  Overview  of  the  VHDL  Language  and  Technology") 

Design  files  may  be  complete  or  partial.  To  support  partial  design  data,  VHDL  can 
read  and  write  external  files.  (VHDL  Language  Requirements) 

All  of  these  formats  provide  provisions  for  handling  data  not  defined  by  the  format 
semantics.  In  EDIF,  this  is  done  with  a  userdata  construct.  In  IGES,  there  is  a  copious 
data  entity.  Both  IPC-D-35x  series  and  VHDL  handle  comments.  There  are  positive  and 
negative  aspects  to  the  use  of  user-defined  data  extensions.  These  constructs  serve  as 
escape  hatches,  necessary  when  unanticipated  data  requirements  become  known.  At  the 
same  time,  however,  their  use  requires  coordination  between  the  sender  of  the  data  and  the 
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receiver  of  the  data.  This  renders  the  data  unacceptable  for  archival  storage  without  the  use 
of  accompanying  documentation. 

I.  FUTURE  PROSPECTS 

IPC  is  continuing  to  upgrade  and  standardize  the  IPC-D-35x  specifications.  Future 
activities  will  focus  on  meeting  DoD  objectives.  If  necessary,  the  language  will  be  changed 
to  meet  users'  needs.  The  users  group  is  working  on  several  guides  to  aid  implementers  of 
the  specifications.  These  guides  include  a  manual  for  Electronic  Packaging  Design  and  a 
"Plan  to  coordinate  the  automation  efforts  of  IPC  committees  directed  toward  the 
development  of  a  totally  integrated  facility."  IPC  leaders  have  identified  six  factors  which 
have  hindered  the  success  of  the  specifications: 

( 1 )  too  much  implementation  inflexibility, 

(2)  minimum  support  by  CAD  system  vendors, 

(3)  industry  usage  abuse, 

(4)  inadequate  training/promotion/visibility, 

(5)  inexperience  of  tri-Service  personnel,  and 

(6)  the  lack  of  public  domain  tools  (translators). 

They  are  working  on  correcting  these  concerns.  (See  Appendix  L.) 

The  IGES  organization  is  continuing  the  refinement  and  enhancement  of  IGES.  It 
will  be  distributing  a  draft  of  IGES  Version  4.0  at  its  quarterly  meeting  in  July  1987. 
Target  publication  date  is  in  3  to  6  months.  Version  4.0  contains  one  form  of  solids  model, 
constructive  solids  geometry  (CSG).  This  is  necessary  for  representing  a  complete  3-D 
assembly  drawing,  suitable  for  documentation.  The  entities  for  the  CSG  models  were 
derived  from  SDRC's  (a  subsidiary  of  CALMA)  CSG  representations.  The  technical 
content  of  Version  5.0  will  be  closed  at  the  end  of  the  July  1987  meeting.  Version  5.0  will 
contain  the  boundary-representation  (b-rep)  solids  modeling  and  design  rule  representation 
capabilities.  High  priority  is  being  placed  on  developing  testing  methodologies  for  the 
format.  A  SAE  certification  program  to  certify  the  compliance  of  commercial  IGES 
translators  with  vendor  claims  is  under  formation.  IGES  3.0  is  in  the  final  stages  of 
approval  as  an  ANSI  standard  by  the  ANSC  Y14.26  Committee.  At  some  point  in  the 
future,  after  the  viability  of  PDES  is  certain,  the  refinement  of  IGES  may  discontinue.  At 
this  time,  Version  5.0  is  the  last  planned  revision  to  IGES. 


34 


With  the  release  of  Version  2.0,  the  EDIF  leadership  will  be  concentrating  on 
promoting  EDIF.  The  first  commercial  EDEF  training  session  will  be  held  in  August  1987. 
The  technical  subcommittees  are  preparing  user  guides.  The  guides  will  be  released 
throughout  1987.  By  late  1987,  an  EDIF  User's  Guide  will  be  published  by  the 
organization.  Many  people  are  still  interested  in  extending  the  scope  of  EDIF.  There  is  a 
movement  underway  to  incorporate  Computer-Aided  Software  Engineering  (CASE)  design 
descriptions  into  EDIF  (Cadre  Technologies,  Inc.).  Other  appropriate  applications  include 
reliability,  availability,  and  maintainability  (RAMCAD)  design  data.  There  is  also  interest 
in  developing  a  bridge  between  EDIF  and  VHDL. 

Version  2.0  is  an  Electronics  Industry  Association  (EIA)  Interim  Standard.  This 
was  published  without  "necessarily  following  the  rigorous  public  review  and  resolution 
and  comments  which  is  a  procedural  part  of  the  development  of  an  EIA  Recommended 
Standard"  (EDIF  Version  2.0).  The  EDIF  organization  will  be  pursuing  standardization  of 
the  format  through  formal  review  and  balloting  procedures.  The  EIA  has  established  a 
formal  structure  comprised  of  an  EDIF  Steering  Committee  and  Technical  Committee. 
Corporate  members  of  EIA  may  join  the  EDIF  Technical  Committee  under  the  EIA. 
According  to  the  press,  EDIF  will  be  accepted. 

Balloting  for  the  IEEE  version  of  VHDL  closed  July  1987.  VHDL  1076/b  was 
approved  by  the  voting  constituency  by  88  percent.  The  VHDL  Analysis  and 
Standardization  Group  (VASG)  plans  to  respond  to  all  comments  received  during  the 
balloting  phase.  IEEE  approved  VHDL  in  December  1987.  Many  believe  that  the  vendor 
community  will  develop  and  release  support  tools  (such  as  simulators  and  interpreters)  and 
VHDL  models  within  six  months  of  IEEE  approval.  There  are  related  projects  underway. 
For  instance,  CLSI  is  creating  a  toolkit  which  includes  VHDL  and  EDIF  conceptual 
schemas  (in  the  Interface  Definition  Language),  data  access  tools,  and  tools  which  allow 
the  importation  of  VHDL  and  EDIF  into  a  central  data  repository.  A  new  IEEE  DASS 
Working  Group  has  been  formed  to  develop  VHDL  models  of  abstract  behavior.  These 
models  will  include  commonly  used  functions  in  the  design  process. 

DoD  projects  (such  as  the  Engineering  Information  System  and  the  Tester 
Independent  Software  Support  System)  are  investigating  the  use  of  VHDL  as  an  interface 
in  an  open  system  engineering  environment.  The  Air  Force  is  funding  10  demonstration 
projects  and  the  development  of  an  interface  between  EDIF  and  VHDL.  There  are  tentative 
plans  to  issue  a  DoD  directive  which  mandates  the  use  of  VHDL  for  all  circuits  delivered  to 
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the  government.  More  extensive  experience  with  the  applicability  of  VHDL  in  various 
environments  is  needed  before  a  directive  of  this  sort  is  accepted. 

There  is  general  agreement  that,  as  a  documentation  language  for  the  behavioral 
functions  of  hardware  design,  VHDL  is  powerful.  The  extent  to  which  any  programming- 
oriented  hardware  design  language  will  be  used  for  design  entry,  however,  is  in  question. 
Designers  are  not  necessarily  programmers  and  may  prefer  a  graphics-oriented  interface. 
In  "STDL:  A  Graphical  Behavior  Language,"  Hakan  Soderstrom  writes,  "We  believe  that 
state  diagrams  are  closer  to  the  way  a  hardware  designer  thinks  than  a  Pascal-likc  textual 
language." 

CAE  vendors  are  exploring  the  board  and  system-level  design  market.  In  the  recent 
past,  the  CAE  vendors'  focus  was  on  chip-level  design  tools.  As  vendors  enter  the 
system-level  market,  the  applicability  of  VHDL  in  the  commercial  arena  will  be  better 
understood. 

The  future  of  PDES  depends  on  the  organization  of  the  PDES  Cooperative  and  the 
volunteer  effort.  A  proposed  scenario  for  the  redirection  of  PDES  is  illustrated  in  Figure 
II-2.  The  future  plans  of  these  organizations  are  summarized  in  Table  II-5. 

General  comments: 

( 1 )  The  IGES  organization  has  made  tentative  plans  to  eventually  replace  IGES 
with  PDES.  None  of  the  other  organizations  have  made  official  statements 
regarding  when  or  at  what  point  the  standards  will  be  complete  or  replaced. 

(2)  All  of  the  standards  are  affiliated  with  an  ANSI-approved  standardization 
organization,  and  are  in  the  process  of  being  approved  or  have  been  approved 
as  an  ANSI  standard. 

(3)  The  ongoing  success  of  the  standards  is  dependent  on  CAE/CAD  vendor 
support. 

(4)  Testing  is  perhaps  the  most  critical  element  of  the  acceptance  of  these  formats. 
The  testing  plans  for  each  of  the  formats,  as  reported  in  the  NBS  Plan  for 
Validation  ( Conformance  Testing)  of  Computer  Products  in  Support  of  the 
CALS  Program,  is  summarized  in  Table  II-6.  The  charts  in  this  table  highlight 
the  fact  that  IGES  has  the  most  complete  plans  for  testing.  The  other 
organizations  are  depending  on  informal  trial  transfers  and/or  pilot  programs 
such  as  EIS  to  demonstrate  the  capability  for  transfer. 
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APPLICATION 
GUIDELINES 
will  define: 


Product  Data  Planning  Model 


ROAD  MAP  for 


C 


Configuration  \ 
Definition 


Shape/S  iz<T''N 
^ — Definitions^ 


C  Physical  "N, 
Character 


Operational 

Character 


INTEGRATED  to  form 


Integrated  Product  Data  Model 
(Logical  Layer  or  Conceptual  Schema) 


IMPLEMENTATDN 
GUIDELINES  will 
define  mappings 
(via  EXPRESS,  SQL, 
etc.) 


Physical  Layer 


Internal  Schemas 
(physical  formats) 


Figure  11-2.  Development  Strategy  for  the  Product  Data  Exchange  Specification 
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Table  11-5.  Plans  of  Standards  Development  Organizations 


PLANS 

ICP-D-35X 

IGES 

EDIF 

VHDL 

Near  Term 

Establish  a  user 
group. 

Release  user 
guidelines. 

Enhancements 
driven  by  aerospace 
and  manufacturing 
industry.  Technical 
content  freeze  at 
Version  5.0. 

Primary  emphasis 
on  testing  program 
(SAE). 

Enhancements 
driven  by  1C  and 
systems  designs 
and  manufacturing 
industries.  Seek 
endorsement  by  EIA. 

Trial  transfers  and 
implementations, 
and  user  guidelines. 

Tool  development 
underway. 

Long  Term 

Mappings  from  IGES 
to  PDES 
(co-existence 
strategies?). 

Interfaces  to  VHDL 

(co-existence 

strategies?). 

Interfaces  to  EDIF 

(co-existence 

strategies?). 

J.  CONCLUSIONS 

Sections  A  through  I  provide  evidence  that  all  of  these  formats/languages  are  viable 
representations  for  specific  application  information.  They  arc  useful  subsets  of  product 
data  and  meet  the  needs  of  the  target  user  community.  Many  organizations  have  invested  a 
substantial  amount  of  manpower  and  other  resources  to  advance  the  development  and  use 
of  the  formats.  None  of  these  formats  will  be  or  should  be  discarded  or  dismissed 
prematurely.  Much  can  be  gained  from  an  in-depth  understanding  of  the  concepts 
introduced  in  this  section.  There  are  two  areas  in  particular  which  need  further 
investigation: 

(1)  the  strengths  and  weaknesses  of  the  formats,  and 

(2)  the  applicability  of  data  modeling  techniques  to  the  analysis  of  the  semantic 
content  of  the  formats. 

Item  (2)  is  discussed  in  Chapters  II  and  III  of  this  report. 

Appendices  B  and  G  and  Supporting  Materials  5,  6,  7,  10,  11,  12,  14,  15,  16,  19, 
20,  21,  25,  and  26  provide  additional  background  material  for  the  information  discussed  in 
this  chapter. 
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Table  11-6.  NBS  Conformance  Testing  for  Product  Data 


III.  COORDINATION  ACTIVITIES 


This  section  describes  three  independent  efforts  to  investigate  the  interoperability  of 
the  exchange  formats  described  in  this  report.  Issues  addressed  include: 

(1)  What  format  or  formats  should  be  used  to  integrate  CAE/CAD/CAM  tools  and 
databases? 

(2)  Will  one  format  ultimately  take  over  the  domain  of  the  others,  thereby 
rendering  implementations  useless? 

(3)  What  formats  will  the  government  require  to  deliver  product  data?  and 

(4)  What  interfaces  among  the  formats  are  needed? 

The  efforts  described  in  this  section,  the  December  17,  1986  Electronics  Standards 
Coordination  Meeting,  the  American  National  Standards  Committee  (ANSC)  Y14.26 
Electronic  Product  Working  Group,  and  the  IEEE  Design  Automation  Standards 
Subcommittee  (DASS),  are  three  of  many  efforts  concerned  with  this  problem. 

Informal  industry  collaborations  are  taking  place  to  minimize  the  risks  of  supporting 
one  or  more  of  the  formats.  For  instance,  Hewlett-Packard  and  McDonnell  Douglas 
Corporation  co-authored  a  letter  dated  20  March  1987  "to  solicit  some  information 
regarding  current  and  future  standards  work  in  the  CAE/CAD/CAM  community.” 
(Supporting  Material  10,  Enclosure  8.3)  The  letter  asked  Mike  Waters  (EDIF  Technical 
Committee  Chairman),  Brad  Smith  (IGES  Program  Manager),  Larry  O'Connell  (IGES 
Electrical  Applications  Subcommittee  Chairman),  Dieter  Bergman  (IPC  Technical  Director), 
and  Larry  Saunders  (IEEE/DASS  VHDL  Analysis  and  Standardization  Working  Group 
Chairman)  questions  regarding  the  objectives,  users,  and  positioning  within  the  standards 
community.  This  information  will  be  used  to  guide  Hewlett-Packard's  and  McDonnell 
Douglas'  long-range  strategic  plans  in  this  area. 
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A.  THE  DECEMBER  17,  1986,  ELECTRONICS  STANDARDS 
COORDINATION  MEETING 

The  Electronics  Standards  Coordination  Meeting  was  a  joint  effort  of  the  OSD 
CALS  Policy  Office  and  IDA.  (See  Supporting  Materials  9,  13,  and  14  and  Appendix  L.) 
The  objectives  of  this  meeting  were  to: 

(1)  understand  the  interaction  of  the  leading  CAE  standards  with  respect  to  DoD's 
requirements,  and 

(2)  reach  an  agreement  on  the  appropriate  approach  to  resolve  the  overlap  issue. 

The  leaders  of  the  standards  development  efforts,  the  Chairman  of  the  IEEE  Design 
Automation  Standards  Subcommittee,  OSD  representatives,  and  IDA  representatives 
participated  in  this  meeting.  A  draft  "Logistics  Information  Model  for  Electronic 
Equipment  (the  Matrix)"  was  presented  by  the  OSD  representatives  as  a  structure  for 
understanding  the  applicability  of  the  standards  in  terms  of  DoD  information  needs.  After 
much  discussion  regarding  the  information  and  application  categories  defined  by  the 
matrix,  two  recommendations  and  several  follow-up  actions  were  agreed  on.  The 
recommendations  were: 

( 1 )  "A  case  study  describing  the  acquisition  process  of  an  electronic  product  model 
from  the  CALS  perspective  should  be  developed." 

(2)  "DoD  should  leverage  the  work  that  is  underway  by  the  various  standards 
organizations  (i.e.,  the  CAL  POLY  data  modeling  project)." 

In  response  to  these  recommendations,  John  Hines  of  the  VHDL  Program  Office  agreed  to 
support  the  development  of  the  Electronic  Product  Case  History.  OSD  tasked  the  National 
Bureau  of  Standards  to  coordinate  the  development  of  the  matrix  with  the  various  standards 
and  industry  organizations  working  on  the  same  problem. 

Specific  follow-up  actions  were  established  to  secure  the  ongoing  participation  of 
the  standards  groups  in  the  refinement  of  the  information  categories  and  completion  of  the 
matrix.  The  standards  leaders  agreed  to  review,  revise,  comment  on,  and  distribute  the 
matrix  to  members  of  the  standards  organizations.  The  group  agreed  on  an  ambitious  draft 
schedule,  which  included  applications  and  standards  committee  workshops. 

This  meeting  was  successful  in  bringing  together  the  leaders  of  the  standards 
groups  to  discuss  each  others'  goals  and  plans  in  terms  of  DoD's  needs.  The  meeting  did 
not,  however,  provide  a  forum  for  defining  specific  domains  for  the  standards  as  some  of 
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the  participants  expected.  These  participants  felt  such  an  agreement  would  be  necessary  to 
ensure  the  future  existence  and  interoperability  of  each  format. 

The  follow-up  actions  did  not  take  place  as  planned.  Due  to  unforeseen 
complications,  the  development  of  the  matrix  structure  was  tasked  to  the  CALS  NSIA 
Committee.  The  results  of  that  effort  will  be  released  by  the  OSD  CALS  Office  in  the  fall 
1987.  This  version  of  the  matrix  should  describe  information  categories  needed  for 
particular  logistics  applications,  as  identified  by  NSIA  subgroups. 

B .  THE  ANSC  Y14.26  ELECTRONIC  PRODUCT  WORKING  GROUP 

The  ANSC  Y14.26  Committee,  titled  "Computer  Aided  Preparation  of  Product 
Definition  Data,"  is  responsible  for  approving  standards  for  product  data  exchange  (i.e., 
IGES  3.0,  IPC-D-35x,  and  EDIF).  Additionally,  this  group  is  concerned  with  the  overlap 
between  product  data  exchange  standards:  namely,  the  overlaps  which  exist  between  IGES 
and  EDIF;  and  peripherally  among  IGES,  EDIF,  VHDL,  and  IPC-D-35x.  The  Electrical 
Liaison  Subgroup,  under  Y14.26,  is  investigating  overlap  issues  raised  by  the  Y14.26 
Committee.  These  issues  include: 

( 1 )  the  current  proliferation  of  overlapping  standards, 

(2)  divergent  technical  approaches  philosophies,  and 

(3)  DoD  policy. 

In  September,  the  Electrical  Liaison  Group  invited  members  of  EDIF  (Dick  Smith,  Mike 
Waters,  and  Jeff  LaVell)  and  IGES  (Larry  O'Connell  and  Brad  Smith  [member  of 
Y14.26])  to  a  meeting  to  discuss  the  EDIF/IGES  overlap.  The  EDIF  position,  expressed  at 
this  meeting,  is  as  follows: 

(1)  The  EDIF  Steering  Committee  could  not  identify  a  standard  functionally 
equivalent  to  EDIF. 

(2)  A  variety  of  standards  are  needed  to  describe  a  product. 

(3)  EDIF  is  best  suited  for  electrical  applications,  IGES  for  mechanical,  and 
VHDL  for  system-level  applications. 

(4)  It  is  up  to  industry  to  determine  how  the  standards  will  be  used. 

(5)  EDIF  people  will  not  participate  in  a  coordination  activity  until  the  release  of 
EDIF  version  2.00. 

The  IGES  position,  according  to  Larry  O'Connell,  the  IGES  Electrical  Applications 
Chairman,  and  Brad  Smith,  the  IGES  Program  Manager,  is  as  follows: 
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(1)  IGES  can  be  used  for  IC  design  data. 

(2)  A  conceptual  data  model  is  required  to  understand  the  overlaps  among  the 
formats. 

(3)  An  industry  team,  the  CAL  POLY  Task  Team,  will  be  attempting  to  create  a 
conceptual  data  model  for  electronic  product  data. 

(4)  EDIF,  VHDL,  and  IGES  people  should  be  involved  in  this  effort. 

(5)  A  bridge  is  necessary  among  the  standards.  For  example,  EDIF  be  used  for 
component  descriptions  and  IGES  be  used  to  build  the  circuit  and  archive  the 
final  product. 

As  a  result  of  the  EDIF  and  IGES  presentations,  the  Y  14.26  Electrical  Liaison 
Group  recommended  the  following  actions: 

(1)  "Focus  on  the  content  of  the  formats  to  bring  convergence," 

(2)  "Pursue  the  joint  modeling  project," 

(3)  "Encourage  a  continuous  dialogue  between  the  Smith  brothers," 

(4)  "Encourage  DoD  to  formulate  a  consistent  and  coordinated  policy  with  respect 
to  product  definition  data  standards," 

(5)  "Pursue  the  formulation  and  promulgation  of  a  formal  memo  of  understanding 
and  agreement  for  a  long  range  plan  for  interoperability  of  recognized  electrical 
product  definition  data  specifications  and  standards,"  and 

(6)  "Recruit  EDIF  and  VHDL  experts  to  work  with  Y  14.26." 

(Supporting  Material  21) 

A  draft  memo,  suggesting  the  preparation  of  a  long-range  plan  for  the 
interoperability  of  Electrical  Product  Specifications,  has  been  prepared.  This  memo,  if 
signed  by  the  leaders  of  the  standards  projects  and  the  chairmen  of  interested  ANSI,  IEEE, 
and  EIA  committees,  will  be  the  first  formal  agreement  by  all  of  the  standards  development 
and  endorsement  groups. 

The  group  is  tracking  the  development  of  the  standards  efforts  and  the  information 
modeling  projects. 

C.  THE  IEEE  DESIGN  AUTOMATION  STANDARDS  SUBCOMMITTEE 

The  Design  Automation  Standards  Subcommittee  (DASS),  under  the  IEEE 
Computer  Society  Design  Automation  Technical  Committee  (IEEE/CS/DATC),  provides 
"standard  description  languages  for  the  capture,  utilization,  and  communication  of 
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electronic  design  data."  (Supporting  Material  7)  Throughout  1986  and  1987  the  DASS  has 
been  focusing  on  the  standardization  of  VHDL  and  the  preparation  of  supporting  technical 
material. 

With  respect  to  standards  for  the  electronics  design  industry,  the  DASS  is 
coordinating  efforts  to  define  interfaces  among  overlapping  standards.  For  the  last  two 
years,  Ron  Waxman,  DASS  Chairman,  has  run  a  panel  presentation  at  the  Design 
Automation  Conference  to  discuss  issues  relating  to  the  interoperability  of  the  standards. 
The  healthy  attendance  at  these  public  forums  suggests  growing  concern  regarding  the 
overlap  issue  within  the  design  automation  community.  The  DASS  has  made  many 
attempts  to  address  and  resolve  the  interoperability  issue.  During  the  period,  fall  1986  to 
spring  1987,  it  lent  support  to  the  development  of  a  conceptual  information  model  for 
electronics  engineering  data,  under  development  by  an  ad  hoc  group  called  the  CAL  Poly 
Task  Team.  At  the  conclusion  of  the  CAL  Poly  effort,  it  became  apparent  that  the  resulting 
model,  although  academically  interesting,  was  not  sufficient  for  solving  the  interoperability 
issues.  The  model  was  not  universally  understandable  and  agreed  upon.  Furthermore, 
procedures  for  mapping  the  model  to  the  various  formats  were  not  defined. 

At  the  July  1987  DASS  meeting,  priorities  concerning  the  interoperability  issue 
were  established.  The  immediate  priority  became  delivery  of  an  interface  between  EDIF 
and  VHDL.  The  use  of  information  models  was  deferred. 

D.  ANALYSIS 

From  the  experiences  of  these  coordination  efforts  we  have  learned  a  great  deal 
about  the  applicability  of  the  four  solutions  to  the  interoperability  issue  listed  in  the 
Introduction  (Chapter  I,  Section  D).  The  following  is  a  summary  of  what  was  learned: 

Solution  1:  Secure  an  agreement  among  the  standards  leaders  to  limit  the  scopes  of 

the  standards. 

Implementation  time  table  :  immediate 

Probability  of  success  :  low 

Critical  success  factors  : 

(a)  identification  of  appropriate  scope  boundaries  that  meet  all  long-range 
expectations 

(b)  adherence  to  the  scope  boundaries  by  EVERYONE  involved  in  the 
development  and  implementation  activities. 
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Solution  2:  Define  interfaces  among  the  formats  without  a  rigorous  specification  of 
the  content  overlaps. 

Implementation  time  table  :  1-2  years 

Probability  of  success  :  good 

Critical  success  factors  : 

(a)  the  successful  interaction  of  format  experts 

(b)  the  identification  of  workable  subsets  of  the  formats 

(c)  well  organized  trial  transfers  and  demonstrations. 

Solution  3:  Develop  one  standard  which  will  handle  all  product  data  for  all 
applications. 

Implementation  time  table  :  5+  years 
Probability  of  success  :  extremely  low 
Critical  success  factors  : 

(a)  a  rigorous  understanding  of  what  product  data  is  by  all  participants 

(b)  full-time  basic  research  on  information  modeling  for  engineering  data 

(c)  the  successful  interaction  of  a  large  number  of  specialists  from  a  wide  spectrum 
of  engineering  disciplines. 

(d)  a  demonstration  of  the  full  development  methodology  for  workable  subset  of 
product  data 

(e)  the  availability  of  automated  tools  to  support  the  development  methodology 
(emphasis  on  the  information  modeling  process) 

(f)  the  successful  reorganization  and  redirection  of  a  PDES-like  effort;  well 
defined  objectives  for  the  project 

Solution  4:  Use  well-defined  areas  of  overlap  as  bridges  among  the  standards. 
Implementation  time  table  :  2-3  years 
Probability  of  success  :  good 
Critical  success  factors  : 


(a)  the  availability  of  an  understandable  and  validated  conceptual  information 
model  and  modeling  methodology  for  electronic  product  data 

(b)  a  systematic  methodology  for  defining  mappings  between  the  conceptual  data 
model  and  the  formats 


(c)  the  cooperation  of  specialists  from  the  electronics  community 

(d)  the  availability  of  automated  tools  which  support  the  systematic  methodology. 


E.  CONCLUSION 

Many  programs  depend  on  the  successful  interoperability  of  existing  standards  to 
achieve  open  system  environments.  Private  industry,  the  defense  industry,  and  non-profit 
organizations  are  involved  in  these  programs  and  need  to  find  solutions.  The  coordination 
efforts  described  above  and  others  have  made  much  progress  toward  understanding  what 
can  be  done  to  define  interfaces  among  the  standards  and  toward  communicating  their 
concerns  and  needs  to  the  appropriate  organizations.  Interoperability,  however,  is  only  one 
facet  of  the  total  solution  to  open  architectures.  A  more  fundamental  aspect  of  the  problem 
(which  begins  to  meet  the  requirements  for  solution  4,  above)  is  discussed  in  Chapter  IV. 

Both  IEEE  and  EIA  are  the  appropriate  organizations  for  coordinating  the 
development  of  interfaces  among  the  standards.  Methodologies  need  to  be  developed  and 
neutral  positions  established,  however,  before  this  can  be  achieved.  Theoretically,  a 
conceptual  information  model  for  electronic  product  data  is  one  potential  approach  to  solve 
the  overlap  issue. 
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IV.  DATA  MODELING  ACTIVITIES 


Chapter  I  introduced  the  notion  of  a  conceptual  model  of  product  data  requirements 
(also  referred  to  as  a  "conceptual  information  model,"  "conceptual  data  model,"  "conceptual 
schema  for  electronic  product  data,"  and  other  combinations).  As  explained  in  the 
introductory  chapter  concerning  open  architectures,  a  conceptual  data  model  serves  as  a 
foundation  for  an  integration  architecture.  Theoretically,  by  using  a  conceptual  data  model, 
it  is  possible  to  define  interfaces  among  disparate  databases,  design  files,  and  exchange 
formats. 

The  Cal  Poly  Task  Team,  a  proof-of-concept  project,  was  tasked  to  develop  an 
industry-wide  conceptual  information  model  for  electronic  product  data.  The  activity, 
described  in  Section  IV. A,  was  a  good  test  of  whether  or  not  existing  modeling 
methodologies  are  sufficient  to  build  conceptual  schemas  for  engineering  data.  Prior  to 
describing  the  Cal  Poly  experiment,  this  section  describes  what  a  conceptual  data  model  is 
and  why  it  is  important. 

A  conceptual  information  model  is  an  abstract  representation  of  data  requirements 
for  a  wide  variety  of  applications.  These  requirements  are  expressed  in  terms  of 
fundamental  data  elements  and  relationships  among  those  elements.  Traditionally, 
conceptual  data  models  are  used  to  design  an  "enterprise"  database  that  will  be  accessed  for 
a  wide  variety  of  applications.  A  conceptual  data  model  also  serves  as  a  "meta-language"  (a 
language  to  talk  about  other  languages)  for  discussing,  comparing,  and  contrasting  the 
content  of  databases,  design  files,  and  CAE  exchange  standards.  This  communication  is 
achieved  by  defining  mappings  between  a  conceptual  data  model  and  each  of  the  exchange 
standards.  This  results  in  consistent  interfaces  among  the  standards.  (See  Figures  IV- 1 
and  IV-2.) 

A  conceptual  data  model  is  one  that  is  independent  of  all  databases,  application  tools, 
applications,  formats,  or  output  reports.  Independence  is  achieved  when  the  meanings 
contained  in  the  model  do  not  rely  on  the  meanings  assumed  by  a  particular 
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Figure  IV-2.  Use  of  a  Conceptual  Schema 


application,  database,  etc.  A  conceptual  model  depicts  the  concepts  necessary  to  generate 
information  for  a  wide  variety  of  applications,  reports,  and  storage  formats. 

Application  data  models,  on  the  other  hand,  represent  the  data  elements  and 
relationships  used  for  a  particular  application.  Many  people  confuse  these  two  types  of 
data  models.  Creating  a  conceptual  data  model  is  very,  very  difficult.  Creating  an 
application  data  model  is  not  as  difficult,  although  it  does  require  the  successful  interaction 


I 
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of  a  group  of  subject  experts  and  experienced  data  modelers.  To  create  an  application  data 
model,  the  application  is  used  to  set  the  context  for  the  following  steps: 

(1)  identify  input,  output,  and  processing-specific  data  requirements, 

(2)  define  the  relationships  among  the  data  elements  (as  dictated  by  the 
application),  and 

(3)  identify  the  properties  (attributes)  associated  with  each  data  element  (also  as 
dictated  by  the  application). 

Creating  a  conceptual  data  model  requires  the  same  basic  steps  outlined  for  the 
application  data  model.  The  significant  difference  is  that  instead  of  identifying  application- 
specific  data  requirements,  the  data  modeling  team  must  identify  abstract  data  requirements, 
relationships,  and  attributes  which  transcend  applications. 

One  approach  to  developing  conceptual  models  is  to  develop  a  set  of  application 
data  models  prior  to  creating  the  conceptual  data  model.  After  a  set  of  application  data 
models  are  considered  stable  and  complete,  they  should  be  integrated  to  form  a  conceptual 
data  model.  The  integration  process  consists  of  identifying  common  and  inconsistent 
elements  among  the  models,  resolving  differences,  merging  commonalities,  and 
generalizing  (or  removing)  application-specific  elements. 

The  integration  process,  however,  may  be  as  difficult  as  the  process  of  creating  a 
conceptual  data  model  without  the  use  of  application  data  models.  It  is  difficult,  because  at 
any  time  during  the  process  it  is  very  easy  to  lose  perspective  regarding  what  is 
"conceptual"  and  what  is  "application-specific." 

The  original  approach  of  the  PDES  project  was  to  create  application  models  prior  to 
the  conceptual  model  (the  "logical  layer").  As  the  application  models  became  reasonably 
stable,  they  would  be  integrated.  The  integration  of  the  PDES  application  models  has  not 
been  proceeding  as  smoothly  as  expected.  The  integration  of  the  models  was  one  of  the 
least-defined  aspects  of  the  process.  It  is  not  clear  whether  the  difficulties  that  the  PDES 
groups  are  facing  are  due  to  the  fact  that  the  process  is  not  well  understood,  or  whether  the 
process  is  inherently  difficult.  Many  lessons  can  be  learned  from  this  effort. 

Data  modeling  techniques  are  traditionally  associated  with  the  design  and 
development  of  databases.  Neutral  exchange  formats,  although  not  databases,  are  similar 
to  databases  in  that  they  are  mechanisms  for  the  storage  and  transfer  of  data.  Data  models 
provide  definitions  of  data  structures.  Theoretically,  they  can  be  used  to  describe  either 
data  base  schemas  or  exchange  format  structures. 
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A  significant  industry  investment  is  required  to  develop  an  industry-wide 
conceptual  data  model.  It  is  not  only  a  long-term  project  (and  never  truly  finished),  but 
also  it  must  be  accepted  by  a  wide  range  of  industry  representatives  (both  users  and,  most 
importantly,  vendors).  Although  it  serves  as  a  foundation  for  open  system  architectures,  it 
also  presents  a  risk  of  data  exploitation  for  both  CAE  vendors  and  product  designers. 
Many  believe  that  component  models  and  design  data  must  be  kept  proprietary  to  maintain  a 
competitive  edge. 

A .  THE  CAL  POLY  TASK  TEAM  EXPERIMENT 

The  Cal  Poly  Task  Team  was  a  group  of  representatives  from  the  electronics 
industry  who  assembled  to  develop  a  public  domain  conceptual  schema  for  electronic 
product  data.  (See  Appendices  D,  E,  H,  I,  J,  and  K.)  The  Cal  Poly  Task  Team,  an 
outgrowth  of  the  PDES  modeling  activities,  was  organized  by  Curtis  Parks  (General 
Dynamics)  and  Roger  Gale  (D.  Appleton  Co.),  both  heavily  involved  in  PDES.  The 
organizers  felt  that  to  develop  a  model  of  electronic  product  data,  representatives  of  the 
electronics  industry  had  to  be  involved.  The  IEEE  DASS  was  identified  as  the  appropriate 
organization  to  serve  as  the  focal  point  for  the  model  development  activities.  The  IEEE 
DASS  agreed  to  sensor  the  activity  and  formed  a  Working  Group  in  response. 

The  Cal  Poly  Task  Team  project  was  a  six-week  full-time  modeling  activity  that 
took  place  during  January  and  February  1987.  The  team  met  at  the  Kellogg  West  facilities 
of  the  California  State  Polytechnic  University.  There  were  13  on-site  participants  (2  for  the 
entire  session),  3  telephone  contributors,  and  9  who  provided  assistance.  The  participants 
were  from  General  Dynamics,  D.  Appleton  Co.,  McDonnell  Douglas,  Westinghouse, 
Hughes,  IDA  (BITE),  Digital  Equipment  Corporation,  Viewlogic  Systems,  and  STC  Ltd 
(UK). 

Members  of  the  Cal  Poly  Task  Team  were  provided  a  week  of  training  in  the 
EDEFl-x  modeling  language  and  methodology  by  employees  of  the  D.  Appleton  Co.  After 
this  training,  two  3-week  modeling  sessions  were  held.  The  organizers  of  the  project 
participated  throughout  both  sessions.  All  other  participants  attended  either  one  of  the  3- 
week  sessions  or  shorter  periods  of  time. 

The  result  of  this  effort  is  an  IDEF1  -x  data  model  of  electronic  product  data  "which 
is  believed  to  establish  a  basic  structure  of  data  within  which  the  functional  description  can 
be  developed."  (Cal  Poly  Task  Team  Final  Report)  This  model  contains  1 7  entities  which 
describe  functional  hierarchy  and  logical  connectivity.  The  team  tried  to  incorporate  a  third 
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aspect  of  electronic  product  data  behavior,  but  had  much  difficulty  and  decided  to  defer  the 
development  of  this  part  of  the  model  until  later. 

The  model  was  presented  to  the  public  by  the  team  organizers  at  three  locations: 
East  Coast  (Bedford,  Massachusetts);  West  Coast  (Pomona,  California);  and  the  Middle 
Atlantic  region  (Dayton,  Ohio).  An  average  of  20  people  attended  each  of  the  reviews. 
The  following  projects  sent  representatives  to  at  least  one  of  the  reviews: 

Engineering  Information  System  (EIS) 

Tester  Independent  Software  Support  System  (TISSS) 

Product  Data  Definition  Interface  Extension  (PDDIx) 

Product  Data  Exchange  Specification  (PDES) 

Computer-Aided  Acquisition  Logistics  Support  (CALS). 

Many  comments  were  received,  and  the  model  was  modified  as  the  result  of  each  review. 
At  the  conclusion  of  the  Cal  Poly  Task  Team  activities,  the  model  and  the  Cal  Poly  Task 
Team  Final  Report  were  delivered  to  the  IEEE  DASS  and  the  PDES  Electrical  Applications 
Chairmen. 

Theoretically,  the  resultant  model  is  elegant.  Practically,  however,  the  model  is  not 
suitable  for  implementation.  The  modeling  methodology,  IDEFIX,  is  not  appropriate  for 
all  aspects  of  engineering  design  data. 

An  analysis  of  the  CAL  Poly  Task  Team  results  and  lessons  learned  reveals  the 
need  for  extensive  basic  research  into  modeling  methodologies  for  engineering  design  data. 
There  are  many  fundamental  issues  yet  to  be  resolved  concerning  the  modeling 
methodology  (both  the  language  and  the  process)  used  to  develop  a  conceptual  model.  The 
critical  issue  (raised  by  participants  at  the  reviews  of  the  model)  is  that  the  the  IDEFl-x 
language  does  not  have  the  expressive  capabilities  required  for  modeling  complex  design 
data.  Another  very  practical  concern  is  the  availability  of  automated  tools  to  support  the 
modeling  process. 

A  demonstration  of  how  the  model  can  be  used  to  define  interfaces  among  exchange 
formats  was  never  achieved.  (See  Appendix  I.)  Until  such  a  demonstration  is  performed, 
industry  will  continue  to  vacillate  over  the  necessity  of  a  conceptual  data  model. 

Another  fundamental  issue  which  is  inhibiting  the  development  of  industry-wide 
conceptual  data  models  is  the  lack  of  knowledge  regarding  how  to  test  and  validate  such 
models. 
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B .  THE  CAL  POLY  TASK  TEAM  EXTENSION 

The  Cal  Poly  Task  Team  officially  disbanded  after  delivery  of  the  final  report.  As  a 
result  of  recommendations  made  at  the  final  review  in  Dayton,  Ohio,  another  ad  hoc  team, 
the  Cal  Poly  Task  Team  Extension,  was  formed.  The  focus  of  this  effort  is  the 
development  of  a  model  for  printed  wiring  board  data. 

C.  CONCLUSIONS 

Although  the  Cal  Poly  Task  Team  did  not  produce  a  usable  model  for  electronic 
product  data  as  intended,  the  team  did  succeed  in  testing  the  use  of  EDEFIX  for  complex 
design  data.  This  effort  highlights  the  need  for  comprehensive  research  into  data  modeling 
methodologies. 

The  most  significant  results  of  this  effort  are  the  questions  which  remain  to  be 
answered  before  modeling  can  take  place  on  a  wide-scale  basis.  It  is  imperative  that  these 
questions  be  addressed  before  another  ambitious  modeling  project  for  CAE  data  is 
undertaken.  These  questions  are  included  in  Chapter  V,  Conclusion. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


1 .  Do  the  data  exchange  formats  provide  what  is  needed  to  implement  open  system 
architecture? 

Not  completely.  There  are  missing  elements: 

(1)  specifications  which  describe  how  to  use  the  formats  to  represent  classes  of 
information  for  various  applications, 

(2)  interfaces  among  the  formats,  and  most  importantly 

(3)  a  conceptual  model  of  electronic  product  data. 

Although  the  formats  described  throughout  this  paper  are  at  various  stages  of 
development,  none  have  reached  the  stage  of  specification  (as  defined  in  Terminology, 
Chapter  II,  Section  B).  In  other  words,  none  of  these  formats  provide  detailed  instructions 
describing  how  to  create  descriptions  which  will  be  compatible  with  all  other  descriptions 
of  that  genre.  Currently,  to  ensure  data  compatibility  (one  system  can  understand  the  data 
generated  by  another  system),  pre-arranged  conventions  must  be  established  between  the 
sender  and  receiver  of  the  data. 

The  standards  groups  are  responding  to  this  need  by  preparing  "user  guides."  User 
guides  establish  conventions  for  using  the  formats  in  a  variety  of  applications.  The 
preparation  of  user  guides  will  follow  actual  implementations  and  trial  transfers.  The 
development  of  specifications  which  describe  how  to  use  the  various  formats  can  be  greatly 
accelerated  if  the  government  provides  a  structure  and  direction  for  the  preparation  of  the 
specifications.  Programs  such  as  ULCE,  RAMCAD,  CALS,  and  EIS  are  the  appropriate 
vehicles  for  providing  this  direction. 

The  develcpment  of  these  standards  will  proceed  at  a  pace  required  by  users  and  as 
the  electronics  design  community  makes  use  of  the  formats.  If  the  vendors  do  not 
implement  the  formats,  then  there  is  little  chance  that  the  formats  will  receive  widespread 
acceptance.  The  IPC-D-35x  series  may  be  in  this  situation.  With  the  current  set  of 
exchange  formats,  a  great  deal  of  vital  electronic  product  design  data  can  be  exchanged.  As 
technology  advances,  data  requirements  will  change.  It  is  anticipated  that  the  capabilities  of 


the  exchange  formats  will  increase  with  the  advance  of  technology.  It  is  unlikely, 
however,  that  it  will  be  possible  in  the  foreseeable  future  to  create  one  standard  that  does 
everything  for  everybody.  The  PDES  project  is  currently  misdirected.  A  more  realistic 
goal  is  to  create  a  method  for  the  interoperability  of  formats. 

2.  How  should  interfaces  among  the  formats  should  he  built  ? 

A  reasonable  approach  is  to  use  rigorously  defined  overlaps  as  bridges  to  transfer 
data  among  the  formats.  This  is  the  preferred  solution,  because  it  is  technically  viable 
(given  the  development  of  information  modeling  techniques  and  models  for  electronic 
product  data),  and  is  open  to  future  requirements.  It  is  applicable  to  any  electronics  product 
data  exchange  format.  Finally,  the  implementation  of  this  solution  is  not  too  far  off  into  the 
future. 


These  missing  elements  (specifications  for  the  use  of  established  formats  and 
interfaces  among  the  formats)  are  symptoms  of  the  lack  of  a  conceptual  information  model 
for  electronic  product  data.  A  conceptual  model  cannot  be  built,  however,  until  advanced 
modeling  methodologies  are  developed. 

RECOMMENDATIONS: 

Concerning  Information  Modeling: 

( 1 )  Fund  a  basic  research  project  to  answer  the  following  questions: 

(a)  What  is  a  conceptual  model  for  engineering  product  data? 

(b)  What  are  the  requirements  for  a  modeling  methodology  and  language  to 
support  a  conceptual  model  for  engineering  product  data? 

(c)  Are  there  any  existing  data  modeling  methodologies  which  meet  those 
requirements? 

(d)  What  automated  tools  are  necessary  to  support  the  modeling  methodology 
and  the  use  of  the  conceptual  model? 

(e)  How  are  conceptual  data  models  tested  and  validated? 

Concerning  the  Existing  Data  Exchange  Formats  for  Electronic  Product  Data: 

(2)  Staff  a  full-time  team  within  DoD  to  serve  as  a  focal  point  and  central  source  of 
expertise  on  the  activities  of  the  CAE  standards  organizations,  the  standards 
coordination  projects,  related  information  modeling  projects,  and  government 
projects  involving  open-system  architectures  for  CAE/CAD/CAM 
environments. 
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Tasks  for  the  team  include: 

(1)  closely  monitor  the  progress  of  each  CAE  exchange  format, 

(2)  provide  a  consistent  presence  within  those  communities,  and 

(3)  drive  the  development  of  the  formats  to  meet  DoD  requirements. 

(3)  Support  the  development  of  specifications  which  describe  how  to  use  the  CAE 
exchange  standards  for  particular  applications. 

(4)  Support  the  development  of  interfaces  among  the  established  CAE  exchange 
formats. 
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SUPPORTING  MATERIALS 


1 .  Data  Exchange  Standards  Library  Listing  for  24  July  1987. 

2.  RAMCAD  Kickoff  Meeting  at  General  Dynamics,  15  July  1987. 

3 .  Using  EDEFO  to  Model  the  Design  Process:  Operational  Procedures  Guide,  7  May 
1987. 

4.  ED£F  Printed  Circuit  Board  Technical  Subcommittee  Meeting,  19  March  1987. 

5 .  "EDIF  News"  from  EDIF  PCB  TSC  Meeting,  19  March  1987. 

6.  Minutes  of  DASS  Steering  Committee  Meeting,  12  March  1987. 

7 .  IEEE  Conceptual  Schema  Slides,  28  February  1987. 

8.  A  Possible  Approach  to  Logistics  Planning:  Melkanoff  Trip  Report,  13  February 
1987. 

9.  Minutes  of  ANSC  Y14.26  Meeting,  2  February  1987. 

10.  ANSC  Y14.26  Trip  Report,  2  February  1987. 

111.  IGES/PDES  Trip  Report,  30  January  1987. 

12.  CALS  Matrix  Development  Update,  29  January  1987. 

13.  CAE  Standards  Coordination  Meeting  Planning  Notes,  December  1986. 

14.  Trip  Report:  EDIF  User's  Group  Workshop  ICCAD  '86,  10  November  1986. 

15.  EDIF  Joint  Technical  Committee/Subcommittee  Trip  Report,  3  November  1986. 

16.  NBS  Briefings  and  Tour  for  NSIA  Members,  Trip  Report,  30  October  1986. 

1 7.  UMD  RAMCAD  System  Flow  Diagrams,  October  1986. 

18.  EDIF  Printed  Circuit  Board  Technical  Subcommittee  Meeting,  16  October  1986. 

19.  ANSC  Y  14.26  Meeting  Trip  Report,  13  October  1986. 

20.  Minutes  of  the  ANSC  Y14.26  Meeting,  8  October  1986. 
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2 1 .  RAMCAD  Electronic  Packaging  Design  Project  External  Reference  Specification, 
25  September  1986. 

22.  RAMCAD  Technical  Interchange  Meeting,  18  September  1986. 

23.  Report  on  the  Federal  Computer  Conference,  3  September  1986. 

24.  EDIF  Printed  Circuit  Board  Technical  Subcommittee  Trip  Report,  4  August  1986. 

25 .  EDIF  Printed  Circuit  Board  Technical  Subcommittee  Trip  Report,  22  May  1986. 
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DESIGN  AUTOMATED  CONFERENCE  POSITION  PAPER 


Hooded :  A  Meta.- language  fnr  Evaluating  -the  Expressiveness  of  EDIF . 
IGES,  VHDL  sod  other  Representation  Mechanisms 

ML  BREI 
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The  IEEE/CS/DASS  Electronic  Model 
Working  Group  (EMG)  ia  using  data  modeling 
methodologies  to  analyze  the 
interoperability  of  existing  exchange 
formats  for  electronic  product  data.  The 
operational  philosophy  of  the  EMG  is  that  a 
conceptual  a enema  for  shared  product  aata 
can  serve  as  a  meta-language  and  foundation 
for  CAE/CAD/CIM  data  integration. 
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To  properly  assess  the  uses  of  and 
relationships  among  VHDL.  EDIF.  and 
IGES/PDES .  we  must  adopt  a  new  perspective. 
Much  time  has  been  spent  addressing  the 
question,  'are  these  formats  competing  or 
complementary.'  The  consensus  is  that 
these  formats  1)  exist.  2)  have  solid 
support  from  specific  sectors  of  the 
industry.  3)  have  a  reasonable  llt*-sp*n, 
and  4)  will  become  standards  for  a  specific 
set  of  applications.  Given  these  premises 
and  the  notion  that  there  is  wide-spread 
concern  regarding  their  inter-operability, 
it  is  tiSM  to  shift  our  focus  to  a  more 
basic  issue:  Bow  can  we  talk  about  the 
expressive  capabilities  of  EDIF.  IGES/PDES . 
and  VHDL?  In  other  words.  what 
conventions,  languages,  and  mechanisms  are 
required  to  understand  that  which  we  are 
going  to  analyze  (what  is  the  common 
meta-language  for  communicating  about  data 
transfer  formats  and  design  languages). 


The  history  of  the  development  of  EDIF. 
IGES.  and  VHDL  explains  the  latent  need  for 
a  meta-language.  Each  was  developed  by  a 
core  team  of  experts  for  a  specific 
application.  The  language  of  the 
application  served  as  the  meta-language  for 
the  information  content.  Each  format  grew 
independently  and  established  its  own 
vernacular  for  expressing  the  information 
pertinent  to  its  application. 
Unfortunately .  osmosis  has  yet  to  occur.  It 
is  a  challenge  to  discuss  engineering 
product  data  with  EDIF.  IGES.  and  VHDL 
experts'  in  one  room.  Invariably,  this  type 
of  meeting  becomes  s  terminology 
clarification  session  to  establish  a 
neutral  ground  for  the  terms  "everybody 
understands . " 


This  semantic  gap  exists  because  m«.  as 
an  industry,  have  yet  to  define  the 
conceptual  foundation  of  CAE/CAD/CAM 
product  data.  A  conceptual  foundation  is  a 
formal  specification  of 

application- independent  data  and  their 

meanings.  attributes,  and  relationships . 
The  transformation  and  use  of  conceptual 
data  for  an  application  results  in  the 
information  embodied  in  a  format.  The 
conceptual  foundation  is  realised  by  a 
conceptual  schema  (or  model)  for  shared 

product  data. 

To  bridge  the  semantic  gap.  the 
IEEE /D ASS  has  formed  the  Electronic 
Modeling  Worming  Group.  After  determining 
the  technical  feasibility  of  using  data 
modeling  technologies  to  analyse  the 
expressiveness  of  EDIF,  IGES,  and  VHDL. 
the  group  will  define  a  standard  set  of 
meanings  for  the  conceptual  data  of 
electronic  products.  The  "Conceptual 

Schema  for  Shared  Product  Data'  developed 
by  the  Cal  Poly  Task  Team  is  the  catalyst 
for  this  effort.  The  success  of  this  work 
hinges  on  the  cooperation  of 
representatives  from  all  aspects  of  the 
electronics  industry.  All  who  truly 

concerned  with  establishing  a  viable 
solution  for  CAD/CAE/CAM  data  -xchange 
should  be  involved  in  the  definition  of  the 
neutral,  conceptual  model  of  the  data  of 
our  enterprise. 
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PDES  UPDATE,  18  MARCH  1987 


TO:  F.  Riddell.  R.  Gunkei 

FROM:  ML  Brei 
SUBJ :  PDES  Update 
DATE:  May  18.  1987 


**  PDES  UPDATE  ** 


A.  The  PDES  project  is  approaching  a  critical  decision  point.  The 
issue  in  question  is  whether  PDES  should  remain  a  totally  voluntary 
activity  under  NBS,  or  whether  it  should  become  a  fully  funded 
project  under  an  organization  such  as  the  DoD. 

Advocates  for  the  fully-funded  option  include  T.  Moffet.  the  ATF 
and  the  CALS  people.  These  grcups  need  PDES  sooner  than  current 
development  is  proceeding. 

There  are  advantages  tc  keeping  PDES  under  NBS.  NBS  provides  a 
neutral  focal  point  for  the  coordination  of  the  development  effort. 
Under  NBS,  PDES  is  strictly  in  the  public  domain.  If  PDES  becomes 
a  funded  project,  questions  of  ownership  arise. 


B.  This  critical  decision  point  is  the  result  of  attempts  to 
re-organize  and  re-direct  the  PDES  efforts.  For  several  months,  T. 
Moffet  has  been  actively  seeking  funding  sources  for  the  project. 
The  OSD  Cals  Policy  Office  has  responded  by  providing  funds  for  the 
following  tasks : 

-  Develop  a  short-range  plan  for  PDES 

-  Perform  a  comparative  analysis  between  CALS  and  PDES 

-  Develop  a  long-range  plan  for  PDES 

-  Write  a  paper  on  the  technical  environment 

These  tasks  are  being  performed  by  DACOM  and  Battelle.  Battelle  is 
providing  the  logistics  expertise  (poc:  Carolyn  Davis 

202-785-8400)  . 


C.  A  decision  may  be  reached  within  the  next  month.  A  preliminary- 
plan  for  PDES  will  be  sent  to  key  people  (Edit  Committee,  DoD. 
GMAP,  IDS,  AMRF,  PDDI ,  IPAD.  AAAP,  and  NSIA  representatives)  within 
a  week  for  review.  A  formal  review  meeting  will  be  held  in  South 
Carolina  on  June  11,  1987.  At  this  meeting,  the  PDES  plan  will  be 
presented  and  feedback  will  be  requested. 

On  June  17.  1987,  Russ  Shorey  is  holding  a  meeting  to  determine  the 
future  of  PDES  from  the  CALS  perpective. 


D.  Controversy  within  the  PDES  working  groups  concerning  the  purpose 
of  PDES  continues .  There  are  atleast  three  prevailing 
perspectives : 

1.  PDES  is  an  exchange  format 

2.  PDES  is  a  data  structure 

3.  PDES  is  am  integrated  data  model 

If  PDES  is  viewed  an  an  integrated  data  model,  then  it  can  have 
many  uses  including  1  &  2  above.  As  an  integrated  data  model, 

translators  can  be  developed  by  provide  mappings  into  IGES,  EDIF, 
STEP,  or  any  other  relevant  physical  format. 
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ELECTRONIC  MODEL  GROUP 


A  Working  Group  of  the 
IEEE/ CS /CATC 

Design  Autonation  Standards  Subcommittee 


Reply  to  ML  Brei 
In  care  of: 

BITE,  Inc. 

9254  Center  Street 
Manassas,  VA  22110 
703-361-7050 


Prepared  for  :  The  Institute  for  Defense  Analyses 
Date  :  May  8,  1987 


To 

Subject 


Distribution 

Goals  and  Objectives  of  the  EMG 


Enclosures 


(1)  Attendee  List 

(2)  Discussion  Items 


EMG  STRATEGIC  PLANNING  MEETING 
May  1,  1987 

-  REPORT  - 


A  meeting  to  discuss  the  goals  and  objectives  of  the  Electronic 
Model  Working  Group  (EMG)  Has  held  on  May  1.  1987  at  BITE  Inc.  The 
attendee  list  is  enclosed  (1). 

Enclosure  (2)  is  a  list  of  issues  discussed  during  the  meeting.  The 
following  is  a  summary  of  the  key  points  raised  in  response  to  the 
discussion  items . 


1 .  The  Cal  Poly  Conceptual  Schema  for  Electronic  Product  Data 

The  Cal  Poly  Conceptual  schema  is  a  neutral  representation  of  the 
data  primitives  required  for  electronic  product  descriptions.  The 
schema  provides : 

-  semantics  for  the  domain  of  discourse  (for  instance,  what  is 
meant  by  the  word  "signal?”)  and 

-  a  definition  of  existence  dependencies  (a  type  of  data 
constraint)  among  data  primitives. 

The  conceptual  schema  is  independent  of  physical  formats  (such  as 
VHDL,  EDIF,  and  IGES).  It  is  a  high  level  abstraction  of  the  data 
encapsulated  by  such  formats. 
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The  conceptual  schema  has  many  uses.  First  and  foremost.  it 
identifies  the  atomic  data  elements  of  electronic  product 
descriptions.  Secondly,  it  defines  existence  relationships  among 
those  elements.  By  describing  primitive  data  elements,  it  may 
serve  as  a  meta-model  to  analyse  a  specific  subset  of  the  overlaps 
between  physical  formats. 


2.  The  DASS  EMG 

The  EMG  will  provide  recommendations  for  specific  uses  of  the  Cal 
Poly  Conceptual  schema.  The  first  application  which  will  be  dealt 
with  is  the  use  of  the  conceptual  schema  to  understand  the  overlap 
between  VHDL  and  EDIF.  The  scope  of  the  overlap  which  will  be 
analyzed  via  the  Cal  Poly  model  is  believed  to  be  a  small  subset  of 
the  entire  overlap  between  VHDL  and  EDIF.  The  aspects  of  the 
overlap  which  will  be  considered  initially  involve  functional 
connectivity  and  structure. 

The  EMG  will  prepare  a  Recommended  Practices  Document  to  address 
this  application.  This  document  will  provide: 

-  a  list  of  terms  and  associated  meanings 

-  a  definition  of  the  common  atomic  data  elements  within  the 

domain  of  discourse 

-  mapping  specifications  between  the  Cal  Poly  model  and  EDIF, 

the  Cal  Poly  model  and  VHDL,  and  the  Cal  Poly  model  and 
IGES 

-  a  definition  of  the  areas  where  dynamic  data  may  exist 


The  Recommended  Practices  Document  will  help  electrical  engineers 
and  other  concerned  parties  understand  how  to  make  use  of  EDIF  in  a 
VHDL  environment  and  vice-versa.  It  will  be  a  pilot  demonstration 
of  formalizing  the,  use  of  the  Cal  Poly  Conceptual  Schema  to  analyze 
the  semantics  of  independent  physical  formats  for  electronic  design 
data . 


3 .  The  Cal  Poly  Task  Team 

The  Cal  Poly  Task  Team  provided  the  groundwork  for  the  EMG.  The 

Cal  Poly  Task  Team  Final _ Report.  April  30,  1987,  contains  a 

comprehensive  description  of  the  conceptual  schema,  a  list  of 
unresolved  issues,  conclusions,  recommendations,  and  sample 
applications  of  the  model.  The  EMG  will  use  this  document  as  a 
starting  point  for  the  preparation  of  the  Recommended  Practices 
Document . 

Although  the  Cal  Poly  Task  Team  formally  dissolved  as  of  May  1, 
1987,  ad  hoc  modeling  groups  have  formed  to  develop  models  for 


various  aspects  of  electronic  product  data.  The  first  such  ad  hoc 
group  is  concerned  with  the  “actual"  aspects  of  printed  wiring 
boards .  Members  of  this  group  are  from  various  companies  which 
have  identified  a  need  for  a  printed  wiring  board  conceptual  data 
model.  The  first  modeling  session  of  this  group  met  during  the 
week  of  May  4,  1987.  Contact  George  Goldsmith  (714-896-1712)  or 

John  Zimmerman  (816-997-2932)  for  more  information. 

The  models  produced  by  these  ad  hoc  modeling  projects  will  most 
likely  have  a  direct  bearing  on  the  Cal  Poly  Conceptual  Schema. 
For  this  reason,  the  EMG  will  serve  as  a  sounding  board  and  focal 
point  for  these  groups  if  desired. 
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The  ELECTRONIC  MODEL  WORKING  GROUP  (EMG ) 
Strategic  Planning  Meeting 

May  1,  1987 

DISCUSSION  ITEMS 


1.  What  is  the  DASS  perspective  on  the  purpose  of  the  EMG? 

2.  What  is  the  IGES/PDES  Cal  Poly  perspective  on  the  purpose  of  the 
EMG? 

3.  Data  transfer  in  the  chip  design  process  scenario: 

EDIF  — >  VHDL  — >  EDIF 

4.  What  type  of  mapping  should  be  defined  between  EDIF  and  VHDL? 

5.  What  is  the  relationship  between  VHDL  and  the  Cal  Poly  Conceptual 
schema? 

6.  Where  does  IGES  fit  in  the  scenario? 

7.  The  EMG  demonstration  project 
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1.  INTRODUCTION 
1.1  THE  TEAM  HISTORY 

The  Cal  Poly  Task  Team  was  an  outgrowth  of  the  activities  of  the  Product  Data  Exchange  Specification 
(POES)  project  of  the  Initial  Graphics  Exchange  Specification  (IGES)  program  under  the  auspices  of  the 
National  Bureau  of  Standards.  One  of  the  Technical  Committees  of  that  program  is  the  Electrical 
Applications  Subcommittee  (EAC). 

As  a  part  of  the  POES  project,  the  EAC  had  a  requirement  to  develop  a  model  of  the  data  involved  in  the 
design  and  manufacture  of  electrical  and  electronic  products.  This  data  model  would  be  integrated  with 
models  developed  by  other  committees  to  form  what  was  called  the  Logical  Layer  of  the  PDES.  The 
Logical  Layer  is  based  on  the  Conceptual  Schema  of  the  three  schema  idea  developed  by 
ANS1/X3/SPARC  in  the  1970's. 

The  EAC  found  that  it  was  unlikely  to  meet  its  scheduled  objectives  for  the  initial  publication  of  the  PDES 
within  its  normal  operating  mode.  There  were  two  key  factors  involved.  The  first  was  that  the  normal 
pattern  of  meetings  was  that  the  group  met  periodically  for  a  few  days;  usually  as  part  of  an  IGES  quarterly 
meeting.  The  second  factor  was  that  within  the  IGES/PDES  community  it  seemed  difficult  to  reach  a 
sufficient  number  of  people  in  the  field  of  design  and  manufacture  oi  electrical  and  electronic  products. 

There  was  a  conclusion  that  the  solution  to  the  first  factor  was  to  pursue  the  data  model  development 
through  a  series  of  intensive  modeling  activities  by  small  task  groups.  It  was  thought  that  organizations 
with  an  interest  in  the  result  would  commit  people  for  specific,  short,  scheduled  periods.  The  Cal  Poly 
Task  Team  was  the  first  of  such  efforts  to  be  scheduled.  It  was  planned  as  a  six-week  intensive  modeling 
activity.  The  six  weeks  were  to  be  preceded  by  a  week  of  training  in  the  modeling  method  and  followed  by 
a  series  of  three  reviews  of  the  model  at  different  sites. 

The  solution  to  the  second  factor  was  to  find  a  way  to  reach  more  directly  into  the  electrical  and  electronic 
product  community.  To  this  end.  there  were  discussions  with  the  IEEE  leading  to  sponsorship  of  the  Cal 
Poly  Task  Team  as  a  group  performing  within  the  Design  Automation  Standards  Subcommittee  (DASS). 

The  Task  Team  began  Its  activities  the  second  week  of  January  1 987  and  completes  its  formal  activity  with 
the  delivery  of  this  final  report 

1 J2.  ORGANIZATION  OF  THIS  REPORT 

The  body  of  this  report  contains  this  introduction,  a  summary,  the  conceptual  data  model  developed  by 
the  task  team  and  conclusions  and  recommendations.  The  bulk  of  the  report  body  is  the  conceptual  data 
model  developed  by  the  team.  The  model  documentation  includes  a  narrative  explanation.  The  narrative 
is  essentially  the  description  presented  orally  during  the  reviews.  Other  documentation  of  the  model 
consists  of  the  diagrams,  the  glossary  and  the  business  rules. 

Following  the  body  of  the  report  are  7  appendices.  Appendices  A1  and  A2  are  provided  to  expand  upon 
the  understanding  of  the  model  and  its  uses.  Appendices  A3  and  A4  provide  records  of  the  issues  and 
discussions  of  the  participants  in  reaching  the  present  state  of  the  modeL  Also  recorded  in  the  issues  are 
issues  raised  during  the  reviews  of  the  model.  Appendix  A5  is  the  activity  model  used  as  a  scoping  aid. 
Appendices  A6  and  A7  identify  persons  involved  with  the  team  and  reviews  of  the  model. 
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2.  SUMMARY 

2.1  MEMBERSHIP  AND  TRAINING 

The  Task  Team  had  an  administrator,  Curt  Parks,  who  was  a  full-time  participant  throughout  the  te.-.n  of  its 
activities.  Another  member,  Roger  Gale,  participated  at  least  three  days  each  week  and  served  as  expert 
modeler.  Jerry  Kane  spent  the  first  three  weeks  of  the  modeling  period  with  the  team  and  M.  L  Brei  spent 
the  second  three  weeks.  Others  (see  Appendix  A6)  participated  for  varying,  shoner  periods. 

Training  in  the  IDEF1X  modeling  language  and  methodology  was  conducted  in  the  second  week  of 
January  by  Roger  Gale  and  Jim  Savage  from  the  D.  Appleton  Co.  Inc.  .  IDEF1X  was  adopted  tor  this 
activity  because  it  is  the  language  of  choice  for  the  integrated  model  of  PDES. 

IDEF1X  was  developed  by  the  U.S.  Air  Force  ICAM  project  A  manual  describing  the  modeling  language 
and  methodology  is  available  from: 

ICAM  •  CIM  Library 

Air  Force  Wright  Aeronautical  tabs 

AFWAL/MLTC 

Wright  Patterson  AFB,  OH  45433-6533 
United  States  of  America 

2.2  CAL  POLY  TASK  TEAM  SCOPE 

The  team  adopted  an  idea  from  the  POES  Data  Planning  Model  that  from  the  sense  of  a  data  model,  there 
is  a  logical  separation  of  the  functional  description  of  products  from  the  physical  description,  ana  elements 
in  the  data  model  which  establish  the  mapping  of  functions  into  physical  parts.  The  team  further  decided 
to  address  the  functional  description  first  because  there  was  more  work  to  date  in  PDES  on  the  model  of 
’he  physical  data. 

The  Task  Team  started  with  an  initial  scope  that  limited  its  efforts  to  the  data  which  represents  the  data 
defining  the  design  of  electrical  and  electronic  products  at  the  point  of  handoff  for  fabrication  and 
assembly.  In  many  enterprises  this  is  the  Engineering  Release.  The  team  frequently  found  itself 
reexamining  issues  of  Task  Team  scope.  It  found  itself  tangled  in  the  definition  of  the  term 
"Requirements*.  After  considerable  discussion,  It  established  a  concept  that  discriminated  between  data 
which  represents  requirements  which  have  more  than  one  possible  technological  solution  and  data  which 
is  the  description  of  a  design  solution  within  a  specific,  chosen  technology. 

2.3  RESULTS 

The  team  has  produced  a  data  model  which  is  believed  to  establish  a  basic  structure  of  data  within  which 
the  functional  description  can  be  developed.  There  are  three  fundamental  parts  of  this  model.  The  first 
part  is  the  data  which  represents  the  *biQ  of  materiar  (the  functional  hierarchy*  to  electrical  engineers) 
relationships  among  units  of  function.  This  is  the  core  structure  (Defined  Functional  Unit  and  Defined 
Functional  Sub  Unit  Occurrence).  The  second  is  the  entities  and  relationships  within  which  the  data 
describing  characteristics  and  behavior  can  is  identified  (Port.  Electrical  Property  and  Signal  relationships). 
The  third  is  the  data  which  describes  the  way  functional  units  are  connected  in  the  logical  sense  (Link, 
Port  and  Electrical  Node  relationships).  Of  the  two  parts,  the  connectivity  is  the  part  which  seems  most 
complete  and  stable.  There  is  general  agreement  that  the  behavior  pan  is  where  there  is  a  large  amount  of 
work  yet  to  be  accomplished. 
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The  model  has  been  presented  lour  times  to  different  groups  of  interested  persons  tor  understanding 
and  comment.  These  presentations  were  at  Bedford,  Mass.,  hosted  by  Computervision;  at  Pomona. 
CaBf.,  hosted  by  Cal  Poly  University:  at  the  joint  meeting  of  ISO  TC184/SC4/WG1  and  PDES/1GES  in  West 
Pafm  Beach  Florida;  and  in  Dayton,  Ohio  hosted  by  the  CIM  branch  of  the  Ai'  Force. 

The  model  has  been  modified  as  a  result  of  comments  at  those  reviews. 

At  the  review  in  Dayton,  John  Zimmerman  presented  the  results  of  his  comparison  of  the  Cal  Poly  model 
connectivity  data  to  the  IGES  version  3.0  capability.  This  is  discussed  in  more  detail  in  Appendix  A2. 

2.4  WHERE  NOW? 

The  Task  Team  result  is  only  a  beginning.  There  is  considerable  work  yet  to  be  done  before  there  is  a  data 
model  with  enough  entities  and  attributes  to  represent  a  useful  subset  of  all  of  the  possible  data  for 
electrical  and  electronic  products.  Additional  teams  need  to  be  scheduled  and  formed.  The  List  of  issues 
in  Appendix  A3  could  serve  to  set  the  scope  of  specific  task  teams. 

As  part  of  the  development  and  integration  of  POES,  the  model  should  be  further  tested.  There  are  two 
installations  of  a  software  tool  called  JANUS  available  to  the  PDES  efforts.  JANUS  is  a  tool  for  managing, 
testing  and  integrating  data  models  in  the  IDEF1X  language.  One  of  the  installations  is  at  Arizona  State 
University  at  Tempe  with  the  U.S.  Air  Force,  Integrated  InformationSupportSystem  (IISS)  project  test  bed. 
The  other  is  with  the  National  Bureau  of  Standards,  Advanced  Manufacturing  Research  Facility  (AMRF)  in 
Gaithersburg,  Maryland.  The  model  should  be  put  into  one,  or  both,  of  these  test  facilities  and  further 
validation  performed. 
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3.  THE  DATA  MODEL 

3.1  NARRATIVE  EXPLANATION  OF  THE  MODEL 

This  section  of  the  report  provides  a  narrative  explanation  to  the  data  model  similar  to  the  narrative  of  the 
presentations  at  the  various  reviews  and  workshops.  The  reader  is  referred  to  section  3.2  tor  the 
diagrams,  section  3.3  for  the  definitions  of  the  entities  and  attributes,  and  to  section  3.4  tor  the  business 
rules  of  the  model.  The  reader  is  also  invited  to  use  the  test  circuit  and  data  instance  tables  in  appendix 
A1  as  an  aid  to  understanding  the  connectivity  relationships  of  the  model. 

The  diagrams  of  the  model  are  presented  as  a  series  of  IDEF  FEO's.  This  narrative  will  refer  to  the  FEO's 
by  their  identification  which  is  found  in  the  lower  left  comer  of  the  form. 

Thb  reader  is  cautioned  that  this  model  has  not  vet  hecome  concerned  whh  the  data  which  tranks  rhann°<; 
IQ  design.  Whan  Ida  concepts  ol  'versions'  Qi  designs  arg  considered.  1Q£  model  is  expected  in 
imdarna  soma  change  which  afll  add  to  the  complexity  of  the  kevs  of  the  entities. 

3.1.1  CONNECTIVITY 

FEO'S  1  through  4  develop  the  data  required  to  establish  connectivity  within  a  functional  buildup  through 
levels  of  assembly. 

3.1 .1.1  FEO-1 

This  is  the  core  structure  of  the  functional  model.  It  represents  the  idea  that  a  functional  desenption  of  a 
product  can  be,  and  generally  is.  composed  of  large  units  of  function  which  divide  into  smaller  urits  of 
function  until  the  designer  arrives  at  his  most  discrete  units.  The  design  process  probably  is  an  iterative 
one  of  dividing  large  units  into  smaller  and  combining  small  units  into  a  desired  larger  function. 

Every  identifiable  unit  of  function  appears  as  an  instance  of  a  Defined  Functional  Unit.  A  Defined 
Functional  Unit  may  be  a  component  of  a  higher  functional  assembly  and  it  may  have  components  of  its 
own. 

The  key  of  the  Defined  Functional  Unit  is  a  Functional  Unit  ID.  The  developers  of  the  model  believe  that 
this  is  not  a  "part  number*.  It  is  a  descriptive  name  which  implies  the  function.  [When  this  model  becomes 
a  part  of  the  larger  product  model,  it  is  anticipated  that  there  will  be  some  higher  ievel  context  entities 
whose  keys  win  migrate  to  become  part  of  the  identification  (key)  of  the  Defined  Functional  Unit] 

Each  instance  of  a  Defined  Functional  Sub  Unit  Occurrence  represents  the  data  that  a  Defined  Functional 
Unit  is  used  as  a  component  of  another.  The  key  of  the  Defined  Functional  Sub  Unit  Occurrence  consists 
of  the  concatenation  of  the  identification  of  the  higher  assembly  (Higher  Unit  ID.Func  Unit  ID(FK))  and  a 
unique  identifier  assigned  to  each  component  within  the  higher  assembly.  The  most  familiar  form  of  such 
an  occurrence  identifer  is  a  reference  designator  (this  is  what  is  used  in  the  appendix  A1  examples). 


The  non-key  attribute  of  the  Defined  Functional  Sub  Unit  Occurrence  is  the  migrated  key  (Sub  Unit 
ID.Func  Unit  ID(FK))  of  the  Defined  Functional  Unit  which  is  the  specific  component  in  this  occurrence. 
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These  two  entities  with  their  two  relationships  provide  the  model  for  the  data  which  describes  all  of  the 
levels  of  assembly.  The  key  of  the  Defined  Functional  Unit  at  the  highest  level  of  assembly  will  never 
appear  in  the  Sub  Unit  ID  role  and  the  keys  of  Defined  Functional  Units  at  the  lowest  level  of  assembly  will 
never  appear  in  the  Higher  Unit  ID  role. 

3.1.1  .2  FEO-2 

A  Defined  Functional  Unit  contains  one  or  more  Defined  Functional  Ports.  A  Defined  Functional  Port  is  a 
logical  place  of  access  to  the  function  of  the  Defined  Functional  Unit.  This  is  consistent  with  the  defintion 
in  IEEE  Standard  100.  Whenever  a  logical  point  of  access  is  defined  by  the  designer  as  a  place  of 
functional  connection,  or  by  a  test  engineer  as  a  point  for  functional  test,  that  act  creates  a  Defined 
Functional  Port. 

The  identification  (key)  of  a  Defined  Functional  Port  is  the  migrated  key  of  its  owning  Defined  Functional 
Unit  plus  a  unique  ID  (The  examples  in  appendix  A1  use  a  number). 

3.1.1 .3  FEO-3 

When  a  Defined  Functional  Unit  is  used  more  than  once  in  the  same  higher  assembly,  there  is  a  need  for  a 
unique  identification  for  each  occurrence  of  its  ports  so  that  one  can  be  distinguished  from  another.  This 
is  the  purpose  for  the  Electrical  Node  entity. 

An  Electrical  Node  is  a  specific  instance  of  a  Defined  Functional  Port  within  a  next  higher  functional 
assembly.  Concatenating  the  complete  migrated  key  from  the  Defined  Functional  Sub  Unit  Occurrence 
with  the  Port  ID  from  the  migrated  key  of  the  Defined  Functional  Port  provides  the  unique  identification  of 
each  Electrical  Node. 

The  Functional  Unit  ID(FK)  of  the  Defined  Functional  Port  is  not  required  for  identification  of  the  Electncal 
Node,  so  it  migrates  to  a  non-key  position. 

3.1.1 .4  FEO-4 

Readers  having  difficulty  with  this  portion  of  the  model  are  invited  to  examine  the  test  circuit  and  instance 
table  in  appencfix  A1  as  an  aid. 

Now  that  the  identifications  of  Defined  Functional  Ports  and  Electrical  Nodes  have  been  established,  it  is 
posstole  to  define  logical  connectivity  among  the  functional  units.  It  is  important  to  keep  in  inind  thatofl. 
physical  design  data  jg  present.  Logic*!  connectivity  is  data  that  functional  units  are  tied  together  in 
specific  ways. 

A  Defined  Functional  Unit  which  to  the  definer  is  a  "black  box'  with  no  knowieage  of  its  details  has  no 
known  connectivity  and  therefore  contains  no  Defined  Electrical  Logical  Links. 

A  Defined  Functional  Unit  which  has  known  details  and  connectivity  will  conta  .  one  or  more  Defined 
Electrical  Logical  Links. 

A  Defined  Electrical  Logical  Link  must  contain  at  least  one  Electrical  Node  and  may  contain  more.  This  is 
established  by  one  or  more  related  instances  of  Electrical  Logical  Link  Nodes. 
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A  Defined  Electrical  Logical  Link  may  include  not  more  than  one  Defined  Functional  Port  and  may  include 
none.  This  is  established  by  zero  or  one  related  instance  of  Electrical  Logical  Link  Port. 

Therefore,  the  smallest  possible  Defined  Electrical  Logical  Links  are  composed  of  either,  two  instances  of 
Electrical  Logical  Nodes  or  one  instance  of  Electrical  Logical  Link  Port  and  one  instance  of  Electrical 
Logical  Link  Node. 

Defined  Functional  Ports  and  Electrical  Nodes  cannot  be  members  of  more  than  one  Defined  Electrical 
Logical  Link.  This  is  simply  a  matter  of  logic.  Sines  the  Defined  Electrical  Logical  Link  represents  logical 
points  that  are  electrically  in  common,  joining  two  links  through  a  common  node  would  have  the  effect  of 
joining  two  links  into  a  single  logical  link.  The  same  logic  applies  to  ports. 

Ports  of  Defined  Functional  Units  which  have  not  been  used  in  higher  functional  assemblies  are  not 
members  of  finks.  Electrical  Nodes  which  are  unused  in  the  next  assembly  are  also  not  members  of  links. 

At  this  point,  the  model  provides  for  the  fundamental  data  of  logical  connectivity.  When  the  physical 
solution  data  model  has  been  developed,  there  will  be  some  mapping  from  the  Defined  Electrical  Logical 
Link  to  the  entities  which  establish  the  physical  description  where  that  logical  connectivity  is  implemented. 

3.1.2  BEHAVIOR 

The  next  portions  of  the  model  are  a  limited  set  of  entities  and  relationships  indicating  the  manner  in  which 
the  data  of  behavior  may  be  modeled.  There  seem  to  be  two  kinds  of  behavior  or  characteristics.  One  is  a 
dynamic  sort  of  behavior  which  is  described  as  output  variations  due  to  input  variations.  The  other  seems 
to  be  a  thought  of  as  static  characteristics  such  as  the  those  of  a  fixed  resistor.  FEO's  5,  6  and  7  are  about 
the  dynamic  characteristics  and  FEO  8  about  static  characteristics. 

3.1. 2.1  FEO-5 

Within  the  limited  time  available,  the  team  set  a  narrow  definition  of  "signal".  It  is  defined  for  this  model  as  a 
difference  in  electrical  potential.  That  difference  must  appear  between  two  Defined  Functional  Ports.  This 
is  the  Defined  Electrical  Signal 

The  identification  (key)  of  a  signal  is  a  concatenation  of  the  identification  of  the  two  ports  between  which  it 
is  defined  and  a  signal  ID  which  is  unique  within  the  Defined  Functional  Unit  to  which  the  ports  belong. 

3.1 .2.2  FEO-6 

Because  it  is  sometimes  necessary  to  establish  that  an  output  signal  is  dependent  on  more  than  one  input 
signal  the  model  provides  for  collecting  one  or  more  signals  into  a  Defined  Functional  Unit  Input  State. 
This  is  accomplished  by  the  Defined  Input  State  Signal  entity.  A  Defined  Electrical  Signal  may  not  be  part 
of  any  input  state  or  it  may  be  part  of  one  or  more.  Every  Defined  Functional  Unit  Input  State  must  have  at 
least  one  related  instance  of  Defined  Input  State  SignaL 

3.1 .2.3  FEO-7 

In  this  diagram,  we  see  some  signals  identified  as  Defined  Functional  Unit  Output  Signals.  The  fact  that  an 
output  is  dependent  upon  one  or  more  input  states  of  the  same  functional  unit  is  established  through  the 
Defined  Functional  Unit  Output  Signal  Related  Input  State  entity. 
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The  entity,  Defined  Functional  Unit  Output  Signal  Propagation  Delay  Definition,  is  modeled  to  show  how 
to  provide  for  data  that  an  output  signal  is  only  required  to  be  present  within  a  specified  time  alter  an  input 
state  has  been  established. 

3.1 .2.4  FEO-8 

The  entity,  Defined  Electrical  Property,  is  modeled  to  show  how  the  static  characteristics  of  behavior  or 
function  may  be  introduced  into  the  data  model.  These  are  characteristics  such  as  resistance  and 
inductance.  The  model  is  merely  a  first  guess.  There  is  considerable  work  yet  to  be  accomplished.  It  is 
anticipated  that  a  more  complicated  data  model  will  result  with  many  entities  and  relationships.  However,  it 
is  expected  that  they  will  still  be  related  to  ports  of  functional  units. 

3.1 .2.5  FEO-9.2 

The  functional  designer  may  find  it  necessary  to  collect  Defined  Electrical  Logical  Links  into  groups  in 
order  to  express  a  requirement  applying  to  the  group.  The  Defined  Electrical  Logical  Link  Group  provides 
this  capability.  A  Defined  Electrical  Logical  Link  Group  has  one  or  more  Defined  Electrical  Logical  Group 
Members. 

Two  kinds  of  constraints  may  be  specified  with  regard  to  electrical  logical  links.  A  constraint  which  applies 
only  to  a  single  link  is  provided  by  the  Defined  Electrical  Logical  Intralink  Constraint.  The  idea  here  is  that 
the  functional  designer  can  specify  some  limitation  which  must  be  met  in  the  physical  design  which 
implements  the  function.  An  example  might  be  that  the  link  is  specified  to  be  a  certain  fraction  of  a 
wavelength  at  an  operating  frequency. 

The  other  kind  of  constraint  is  a  requirement  that  the  physical  solution  must  meet  some  specified  funtionai 
condition  between  groups  of  links.  This  is  provided  for  by  the  Defined  Electrical  Logical  Interlink 
Constraint.  Here  is  where  the  physical  design  might  be  constrained  to  some  maximum  capacitance 
between  link  groups. 

The  task  team  did  not  have  time  to  explore  these  constraint  ideas  in  any  detail.  This  is  an  area  of  the  model 
which  could  be  expanded  by  another  modeling  team. 

3.1 .2.6  FEO-IO 

This  is  the  complete  model  developed  by  the  task  team.  FEO's  1  through  9.2  have  provided  the 
explanation  of  the  model  treating  each  major  concept  separately. 

3 .2  MODEL  DIAGRAMS 

The  pages  which  follow  contain  the  FEO's  which  are  the  diagrams  of  the  model 
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3.3  MODEL  GLOSSARY 

3.3.1  ENTITY  DEFINITIONS 

Defined  Electrical  Logical  Intralink  Constraint 

Data  which  sets  limiting  values  (or  a  functional  characterislic,  contained  within  a  single  network,  which 
must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical  connections  are 
implemented.  An  example  might  be  a  length  constraint  in  terms  of  wavelengths  at  a  specified 
operating  frequency. 

Defined  Electrical  Logical  Link 

Data  about  the  logical  electrical  connectivity  within  a  Functional  Unit.  It  establishes  a  set  of  two  or  more 
Electrical  Nodes  or  one  Defined  Functional  Port  and  one  or  more  Electrical  Nodes  as  being  electncally 
in  common. 

Defined  Electrical  Logical  Link  Group 

Data  that  establishes  that  one  or  more  Defined  Electrical  Logical  Links  are  combined  into  a  group  for 
some  purpose. 

Defined  Electrical  Logical  Link  Group  Member 

Data  that  a  Defined  Electrical  Logical  Link  is  a  member  of  a  Defined  Electrical  Logical  Link  Group. 

Defined  Electrical  Logical  Link  Intergroup  Constraint 

Data  which  sets  limiting  values  for  a  functional  characteristic  among  Defined  Electrical  Logical  Link 
Groups  which  must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical 
connections  are  implemented.  Examples  would  be  capacitance  limits  or  an  insulation  resistance 
requirement. 

Defined  Electrical  Property 

Data  about  electrical  characteristics  of  a  Defined  Funtional  Unit  existing  between  two  Defined 
Functional  Ports.  For  example,  resistance,  capacitance  or  inductance  which  are  usually  thought  of  as 
'static*  rather  than  'dynamic*.  (These  properties  do  have  some  variation  such  as  the  temperature 
coefficient  of  resistance  for  a  resistor). 

[Entities  and  attributes  to  capture  the  data  of  these  variations  have  not  yet  been  modeled.] 
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Defined  Electrical  Signal 

Data  used  to  define  the  behavior  of  a  Defined  Functional  Unit,  expressed  in  terms  of  electrical 
potential  difference  between  two  Defined  Functional  Ports.  ( It  is  through  the  data  which  defines  the 
relationships  of  output  signals  to  input  signal  states  that  dynamic  behavior  of  'active*  Defined 
Functional  Units  is  captured.  The  characteristic  curves  of  a  transistor  can  be  derived  by  common, 
curve  fitting  algorithms  from  sets  of  these  data.) 

Defined  Functional  Port 

Data  describing  the  logical  accessibility  to  one  of  the  functions  of  a  Defined  Functional  Unit.  (These 
ports  are  what  is  represented  by  lines  or  other  graphic  symbols  identifying  inputs  and  outputs  for 
electrical  devices.  The  port  is  a  characteristic  of  a  Functional  Unit  definition  without  its  having  a  usage. 
The  port  can  be  thought  of  as  a  window  through  which  the  boundary  networks  of  the  functional  unit 
are  seen.  When  a  Defined  Functional  Unit  is  given  an  instance  of  use  (Defined  Functional  Sub  Unit 
Occurrence),  then  the  port  becomes  an  Electrical  Node  of  its  higher  assembly.) 

Defined  Functional  Sub  Unit  Occurrence 

Data  that  a  particular  Defined  Functional  Unit  occurs  as  a  component  of  another  Defined  Functional 
Unit.  There  is  an  instance  of  this  entity  for  each  occurrence  of  a  Defined  Functional  Unit  within  the 
same  higher  level  Defined  Functional  Unit.  This  provides  a  functional  view  of  the  vanous  levels  of 
component/assembly  product  relationship. 

Defined  Functional  Unit 

Data  about  the  functional,  or  performance,  aspects  of  a  portion  of  a  system.  A  Defined  Functional 
Unit  may  be  a  sub  unit  of  another  Defined  Functional  Unit  and  it  may  have  sub  units  of  its  own. 

Defined  Functional  Unit  Input  State  (a  set  of  stimuli) 

Data  about  conditions  for  a  specific  Functional  Unit.  (Through  the  Defined  Input  State  Signal 
associative  entity,  a  particular  input  state  is  defined  as  consisting  of  one  or  more  Defined  Electrical 
Signals,  in  the  electrical  application.) 

Defined  Functional  Unit  Output  Signal  Related  Input  State 

Data  that  establishes  that  a  Defined  Functional  Unit  Output  Signal  results  from  a  Defined  Functional 
Unit  Input  State. 

Defined  Functional  Unit  Output  Signal 

An  output  signal  of  a  particular  Defined  Functional  Unit 
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Defined  Functional  Unit  Output  Signal  Propagation  Delay  Specification  (response  time) 

Data  that  a  Functional  Unit  Output  Signal  is  required  to  be  present  within  a  specified  time  alter  the 
related  Specified  Functional  Unit  Input  State  has  been  established. 

Defined  Input  State  Signal 

Data  that  establishes  a  particular  Defined  Electrical  Signal  as  being  a  part  of  a  Defined  Functional  Unit 
Input  State. 

Electrical  Logical  Link  Node 

Data  that  an  Electrical  Node  is  part  of  a  Defined  Electrical  Logical  Link. 

Electrical  Logical  Link  Port 

Data  that  a  Defined  Functional  Port  is  part  of  a  Defined  Electrical  Logical  Link.  Each  Defined 
Functional  Port  can  be  a  member  of  only  one  Defined  Electrical  Logical  Link. 

Electrical  Node 

Data  about  a  logical  (functional)  accessability  to  the  functionality  of  a  specific  occurrence  of  a 
Functional  Unit.  This  entity  serves  to  collect  the  Defined  Functional  Port  ID  (e.g..  Pin  Number) 
together  with  the  reference  label  of  the  occurrence  of  the  Defined  Functional  Sub  Unit  Occurrence 
(e.g..  U2-Pin  1). 

3.3.2  ATTRIBUTE  DEFINITIONS 
Defined  Electrical  Property  Name 

The  name  of  a  specific  Electrical  Property  existing  between  two  Ports  of  a  Defined  Functional  Unit. 
These  are  such  names  as  Resistance,  Capacitance,  Inductance,  etc.. 

Defined  Electrical  Property  Units 

Identification  of  the  kind  of  units  in  which  an  Electrical  Property  Value  is  expressed.  Examples  are 
Ohms,  Farads,  etc.. 

Defined  Electrical  Property  Value 

The  value,  or  quantity,  of  an  Electrical  Property 

Delay  Specification 

An  expression  of  a  constraint  of  the  delay  from  the  establishment  of  the  related  Defined  Functional 
Unit  Input  State  before  the  Defined  Functional  Unit  Output  Signal  must  be  present  Most  likely 
expressed  in  time  units. 

[Further  examination  of  this  attrtoute  will  probably  result  in  additional  attributes  and,  perhaps,  entities.] 
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Electrical  Logical  Link  ID 

An  identification  of  an  Electrical  Logical  Link  which  is  unique  within  a  particular  Defined  Functional 
Unit.  May  be  numeric  or  alphabetic. 

Electrical  Logical  Link  Group  ID 

An  identification  of  an  Electrical  Logical  Link  Group  which  is  unique  within  a  particular  Defined 
Functional  Unit  May  be  numeric  or  alphabetic. 

Functional  Unit  ID 

A  unique  identifier  assigned  by  the  enterprise  to  each  Defined  Functional  Unit.  Most  commonly  this  is 
a  meaningful  name.  An  example  might  be  'multiplexer  assembly*. 

[When  the  present  model  is  integrated  into  a  larger  enterprise  or  PDES  conceptual  data  model  it  is 
probable  that  a  completely  unique  identification  will  require  a  concatenation  of  several  attributes. 
These  are  likely  to  include  the  identification  of  the  enterprise  which  establishes  (or  owns)  this 
definition  and  a  product  or  model  identification  as  well  as  a  functional  unit  name.] 

Input  State  ID 

An  identifier  assigned  by  the  enterprise  to  each  input  signal  state  within  the  definition  of  a  Defined 
Functional  Unit  Thus,  the  identifier  is  unique  only  within  the  context  of  a  specific  Defined  Functional 
Unit  and  the  combination  of  Functional  Unit  ID  and  Input  State  ID  is  unique  within  the  enterprise. 

Port  ID 

An  identifier  assigned  to  each  Defined  Functional  Port  of  a  Defined  Functional  Unit. 

Signal  ID 

An  identifier  assigned  to  uniquely  distinguish  a  signal,  which  appears  between  the  same  pair  of  ports, 
from  another. 

( If  the  functional  unit  that  is  being  defined  is  a  digital  unit,  then  typical  signals  are  trains  of  digital 
pulses.  These  can  be  most  simply  defined  as  two  signals,  a  high  and  a  low.  Where  the  functional  unit 
is  something  such  as  a  transistor,  there  could  be  many  signals  defined,  each  having  a  different 
voltage  value.) 

Signal  Units 

Identification  of  the  kind  of  units  in  which  the  value  of  the  signal  is  expressed. 

Signal  Value 

A  numbt '  indicating  the  Quantity  of  the  units  of  the  particular  signal. 
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Sub  Unit  Occurrence  Identification 

An  identification  assigned  to  a  particular  occurrence  of  a  Defined  Functional  Unit  within  another 
Defined  Functional  Unit.  (The  most  common  form  of  this  in  electrical  design  is  a  reference 
designation.  The  same  functional  resistor  used  twice  in  a  higher  unit  might  be  designated  R1  in  one 
occurrence  and  R 2  in  the  other.) 

3.4  BUSINESS  RULES  OF  THE  DATA  MODEL 

This  section  presents  the  business  rules  of  the  E/E  conceptual  model  in  English.  The  rules  are  grouped 
by  entities.  Entity  names  are  distinguished  by  bold  italics.  The  number  scheme  below  does  not 
correspond  to  number  schemes  used  in  other  documentation. 

1 .  A  Defined  Functional  Unit  has  0, 1 .  or  many  Defined  Functional  Unit  input  States. 

2.  A  Defined  Functional  Unit  contains  1 .  or  many  Defined  Functional  Ports. 

3.  A  Defined  Functional  Unit  is  0, 1 .  or  many  Defined  Functional  Sub  Unit  Occurrences. 

4.  A  Defined  Functional  Unit  has  0. 1,  or  many  Defined  Functional  Sub  Unit  Occurrence s. 

5.  A  Defined  Functional  Unit  contains  0, 1.  or  many  Defined  Electrical  Logical  Links. 

6.  A  Defined  Functional  Unit  contains  Q,  1,  or  many  Defined  Electrical  Logical  Link  Groups. 

7.  A  Defined  Functional  Unit  Input  State  is  0,  1 .  or  many  Defined  Functional  Unit  Output  Signal 
Related  Input  States. 

8.  A  Defined  Functional  Unit  Input  State  is  composed  of  1  or  many  Defined  Input  State  Signal. 

9 .  A  Defined  Functional  Port  is  a  reference  port  for  0, 1 ,  or  many  Defined  Electrical  Property!  ies) . 

10.  A  Defined  Functional  Port  is  a  measurement  port  tor  0, 1 .  or  many  Defined  Electrical  Property!  ies). 

11.  A  Defined  Functional  Port  is  a  reference  port  for  0, 1,  or  many  Defined  Electrical  Signals. 

12.  A  Defined  Functional  Port  is  a  measurement  port  for  0, 1 ,  or  many  Defined  Electrical  Signal. 

13.  A  Defined  Functional  Port  is  0  or  1  Electrical  Logical  Link  Ports. 

14.  A  Defined  Functional  Port  becomes  0, 1,  or  many  Electrical  Nodes. 

15.  A  Defined  Functional  Sub  Unit  Occurrence  contains  1 .  or  many  Electrical  Nodes. 

16.  A  Defined  Electrical  Logical  Link  inckjdes  0  or  1  Electrical  Logical  Link  Ports. 

17.  A  Defined  Electrical  Logical  Link  is  composed  of  1  or  many  Electrical  Logical  Link  Nodes. 

18.  A  Defined  Electrical  Logical  Link  has  0, 1 ,  or  many  Defined  Electrical  Logical  IntraUnk  Constraint. 

19.  A  Defined  Electrical  Logical  Link  is  0, 1  or  many  Defined  Electrical  Logical  Group  Members. 
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20.  A  Defined  Electrical  Logical  Link  G/cup  is  me  1st  logical  link  group  of  0, 1,  or  many  Electrical  Logical 
Link  Defined  Constraints. 

21.  A  Defined  Electrical  Logical  Link  Gnxp  is  the  2nd  logical  link  group  of  0,1,  or  many  Electrical 
Logical  Link  Defined  Constraints. 

22.  A  Defined  Electrical  Signal  is  0, 1.  or  many  Defined  Functional  Unit  Output  Signals. 

23.  A  Defined  Electrical  Signal  is  0, 1 ,  or  many  Defined  Input  State  Signals. 

24.  A  Defined  Functional  Unit  Output  Signal  has  0  or  1  Defined  Functional  Unit  Output 
Signal  Propagation  Delay  Definitions. 

25.  A  Defined  Functional  Unit  Output  Signal  results  from  at  least  1  Defined  Functional  Unit  Output 
Signal  Related  Input  State. 

26.  An  Electrical  Node  s  Oort  Electrical  Logical  Link  Nodes. 

4.  CONCLUSIONS  AND  RECOMMENDATIONS 

As  a  result  of  the  modeling  efforts  and  the  subsequent  reviews,  the  core  members  of  the  team  reached 
some  conclusions  and  have  some  recommendations  as  follows: 

4.1  CONCLUSION -THE  PRESENT  MODEL  IS  A  START 

The  present  model  is  seen  by  the  team  as  a  core  structure.  The  connectivity  data  appears  to  be  the  most 
stable  portion  of  the  model. 

The  Defined  Functional  Unit  and  Defined  Functional  Sub  Unit  Occurrence  relationships  will  alter  when  the 
effects  of  change  are  introduced  into  the  modeL  There  is  a  present  concept  in  much  of  the  manufacturing 
industry  that  some  changes  result  in  variations,  or  versions,  of  units  while  others  result  in  new  units.  This 
concept  is  not  covered  in  the  present  modeL 

The  Defined  Functional  Port  seems  to  be  a  strong  idea.  We  believe  that  it  is  the  key  entity  to  which 
behavioral  data  relates.  There  is  a  great  deal  of  work  to  do  in  me  data  of  behavior  and  function. 

There  is  a  need  for  a  data  model  for  the  physical  part  description  of  some  electronic  items.  Then  the 
mapping  between  the  functional  description  and  a  physical  description  can  be  discovered. 

4.2  RECOMMENDATIONS 

4.2.1  MORE  TESTING  IS  REQUIRED 

The  model  should  be  subjected  to  additional  testing  and  verification.  This  needs  to  be  performed  in  a 
more  formal  process  than  the  reviews  conducted  to  date. 

The  model  should  be  entered  into  JANUS  at  the  IISS  Test  Bed  at  ASU  or  the  AMRF  or  both.  In  JANUS, 
the  normalization  of  the  model  should  be  checked. 

After  the  JANUS  verification,  a  database  should  be  created  and  populated  with  data  from  test  case  parts. 
The  database  should  then  be  tested  to  prove  the  data  model  by  performing  test  queries. 
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4.2.2  ADDITIONAL  MODELING  IS  REQUIRED 

4.2.2. 1  Data  for  a  Physical  Part 

It  is  recommended  that  a  sample  printed  circuit  card  assembly  be  adopted  as  a  test  case.  A  modeling  team 
should  work  to  develop  a  data  model  for  the  physical  description  of  the  printed  circuit  card  and  the 
components  which  mount  on  it.  This  team  should  attempt  to  make  use  of  the  mechanical  products  model 
and  the  work  being  performed  on  form  features. 

4 .2.2.2  Change  Data 

The  data  representing  change  needs  to  be  added  to  the  models.  It  is  recommended  that  this  be  deferred 
in  hopes  that  a  specific  team  will  be  formed  to  model  the  data  for  configuration  management. 

4.2.2.3  Function  and  Behavior  Data 

There  is  much  work  to  be  done  for  this  type  of  data.  A  sequence  by  which  this  large  scope  might  be 
attacked  would  be  as  follows: 

a.  Begin  with  the  model  of  functional  data  for  simple  electronic  parts  such  as  resistors  and  capacitors. 
Model  the  characteristics  of  these  one  at  a  time  by  analyzing  the  data  sheets  for  such  devices  and 
developing  appropriate  data  model  extensions. 

b.  Model  'active*  devices  starting  with  simple  devices  such  as  individual  diodes  and  transistors  and 
then  progressing  to  complex  electronic  devices  such  as  integrated  circuits.  Here  again,  the 
approach  should  be  to  analyze  data  sheets  and  specifications  to  determine  the  data  which 
describes  function  and  behavior. 

It  is  believed  that  the  data  resulting  from  these  tasks  is  the  essential  performance  data  required  for  a 
components  library.  As  such  it  should  be  of  considerable  interest  to  industry. 
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1.  TEST  CASE  CIRCUIT  AND  DATA  INSTANCE  TABLE 
1.1  THE  TEST  CIRCUIT 

Figure  A1-1  is  a  simple  schematic  type  of  diagram  providing  a  test  case  with  two  levels  of  assembly.  It  also 
contains  an  example  of  a  part  with  multiple  uses,  some  in  the  same  next  assembly.  It  should  be  noted  that 
there  is  no  idea  of  physical  characteristics  intended  here.  The  schematic  indicates  only  function. 

The  tables  on  the  following  pages  represent  the  data  of  functional  component/assembly  relationships  and 
the  connectivity  of  the  test  case.  Each  table  represents  one  entity  in  the  data  model  and  is  identified  by 
the  entity  name.  Each  row  of  a  table  equates  to  one  instance  of  the  entity.  The  columns  of  the  table  are 
the  attributes  within  the  entity.  The  columns  to  the  lett  of  the  heavy  vertical  line  represent  the  key 
attributes  of  the  entity. 


Figure  A1-1 

I 

I 

I 

I 


D-35 


Naianjaaniw  UNn  woiaNruo*#JM 


IEEE/PDES 
Cal  Poly  Task  Team  Final  Report 
Appendix  A1 
Revised  April  30,1987 


IEEE/PDES 
'ask  Team  Final  Report 
Appendix  A1 
Revised  April30. 1987 


IEEE/PDES 
Cal  Poly  Task  Team  Final  Reporv 
Appendix  A1 
Revised  April  30, 1987 


1.2  TEST  QUERY 

There  is  a  symbol  on  the  test  circuit  indicating  that  Port  4  of  the  Functional  Assembly  is  connected  to 
ground.  The  test  query  is  to  determine  all  of  the  Nodes/Ports  which  are  logically  connected  to  this 
ground. 

On  the  page  which  follows,  the  navigation  through  the  tables  needed  to  answer  the  query  is  shown.  In 
each  row  of  the  table  the  data  needed  to  inquire  is  shown  with  a  dotted  fill  and  the  data  needed  as  the 
answer  is  shown  with  a  heavy  outline.  The  answer  from  one  table  provides  the  query  data  for  the  next 
table  as  well  as  being,  in  some  cases,  part  of  the  answer  to  the  general  Question 
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1.  MAPPING  THE  MODEL  TO  IGES 

At  the  Dayton  review,  John  Zimmerman  presented  a  mapping  he  had  developed  between  the  Cal  Poly 
model  connectivity  and  the  entities  of  IGES  Version  3.0  provided  for  that  purpose.  This  mapping  was  an 
example  of  the  use  of  a  conceptual  schema  model  to  examine  an  internal  schema.  IGES,  as  a  transfer 
format  specification  is  an  example  of  an  internal  schema. 

After  the  Dayton  review,  Curt  Parks  performed  more  analysis  o*  the  mapping  to  IGES.  The  results  of  the 
combination  of  John  Zimmerman  s  and  Curt  Parks'  work  are  discussed  in  this  appendix. 

IGES  is  based  on  the  idea  of  providing  a  standard,  neutral  format  for  exchange  of  files  among  graphics 
systems.  Such  files  represent  "pictures'  to  be  displayed  on  CRTs  along  with  data  which  establishes 
some  meanings  for  the  elements  seen  in  the  pictures.  IGES,  therefore,  includes  entities  which  are 
"graphic"  entities  providing  visual  presentations  of  conceptual  entities  such  as  curves  and  surfaces. 

IGES  provides  entities  by  which  to  transfer  data  present  in  sending  systems.  If  an  originating  system  does 
not  contain  cenain  kinds  of  data,  it  is  not  required  to  appear  in  the  transfer  file.  A  major  difference  of  PDES 
is  the  use  of  a  data  model  to  establish  requiremens  for  data  which  must  be  present  and  meanings  of  the 
data  for  correct  interpretation.  A  PDES  transfer  should  be  interpretable  by  a  computer  program.  An  IGES 
file  may  require  human  interpretation  of  its  presentation  on  a  graphics  screen. 

An  IGES  file  may  be  a  representation  of  an  electrical  schematic.  An  electrical  schematic  is,  basically,  a 
functional  representation.  The  Cal  Poly  model  is  a  functional  model.  Therefore,  the  applicable  mapping  is 
to  the  IGES  schematic  representation. 

An  aid  to  understanding  how  to  use  the  IGES  format  for  electrical  data  is  the  IGES  Version  3.0  Electncal 
Applications  Guide,  EACP-1.4,  dated  6/1/86  available  through  the  IGES  project  at  the  National  Bureau  of 
Standards,  Gaithersburg.  MD. 

It  should  be  noted  that  the  Cal  Poiy  model  is  a  relational  model  describing  data  integrity  by  relationships 
among  entities,  in  the  IGES  file  structure,  relationships  tend  to  be  implemented  as  pointers. 

In  IGES  electrical  schematics,  the  component/assembly  relationship  is  implemented  by  nesting  instances 
of  Network  Subfigures  (entity  420)  which  represent  functional  units  within  others.  The  indication  that  a 
Network  Subfigure  is  a  representation  of  a  functional  unit  is  the  presence  of  a  pointer  to  a  Part  Number 
Property  (entity  406,  form  9)  in  the  Network  Subfigure  Definition  (entity  320).  IGES  permits  the 
identification  of  a  collection  of  entities  in  a  file  which  represent  the  “top  assembly"  as  a  Network  Subfigure. 
However,  this  is  a  case  where  this  is  an  IGES  option.  Thus,  the  mapping  from  the  Cal  Poly  mooel  of  the 
hierarchy  of  functional  units  may  be  "bald  headed*  in  an  IGES  file  because  the  top  assembly  is  not 
explicitly  identified.  (The  identification  of  the  file  itself  in  the  Global  Section  mav  be  the  identification  of  the 
top  assembly). 

Connectivity  in  an  IGES  file  is  established  by  Flow  Associativities  (entity  402  form  18).  A  Flow  Associativity 
“links*  Connect  Points  (entity  132)  logically  together  by  pointers  from  the  Row  Associativity  to  the 
Connect  Point.  Row  Associativities  may  point  to  each  other. 

Both  the  Defined  Functional  Port  and  Electrical  Node  of  the  Cal  Poly  model  map  to  Connect  Points.  IGES 
does  not  make  the  port  and  node  distinctions  made  by  the  model.  It  is  interesting  that  VHDL  does  have 
the  same  distinctions  represented  by  Formal  Port  and  Actual  Port. 


D-43 


IEEE/PDES 
Cal  Poly  Task  Team  Final  Repor7 
Appendix  A2 
Revised  April  30. 1987 


Figure  A2-1  is  the  test  case  circuit  trom  Appendix  A1  modified  to  illustrate  the  way  IGES  implements 
connectivity.  The  filled  squares  are  IGES  Connect  Points  which  represent  Delinec  Functional  Pons  and 
Electrical  Nodes  required  by  the  Cal  Poly  model.  The  open  circles  are  Connect  Points  required  by  IGES  in 
order  to  locate  lines  correctly  on  graphic  schematic  presentations. 

There  is  a  mapping  from  the  Cal  Poly  model  Defined  Electrical  Logical  Link  to  the  IGES  Flow  Associativity. 
However,  there  is  a  subtle  difference.  In  an  IGES  file  for  Figure  A2-1  where  the  component/assemoly 
hierarchy  is  present,  the  connectivity  in  the  Voltage  Divider  between  port  1  ot  R1  and  port  ^  of  the 
Voltage  Divider  would  be  a  Flow  Associativity.  The  connection  in  the  Functional  Assembly  between  port  1 
of  the  Voltage  Divider  and  port  1  of  the  Functional  Assembly  would  be  another  Flow  Associativity.  Each  ot 
these  Row  Associativities  would  include  a  pointer  (CFPTR)  to  the  other  to  establish  the  link  providing  the 
continuity  between  levels  of  the  hierarchy  trom  port  1  of  the  Functional  Assembly  to  port  1  of  R1. 

The  Cal  Poly  model  establishes  this  linkage  through  the  Electrical  Logical  Link  Port  entity  and  the 
relationship  that  identifies  that  same  port  as  an  Electrical  Node  of  a  higher  functional  assembly  (see  the 
examples  in  Appendix  At). 

This  mapping  is  an  example  of  relating  a  conceptual  schema  model  to  one  internal  schema  as  represented 
by  a  file  format  Other  formats  such  as  VHDL  and  EDIF  may  be  related  in  a  similar  manner. 


FUNC  ASSY 


B  CONNECT  WOOBJ  WHICH  MAP  TO  DEFINED 
FUNCTIONAL  FONT  ON  ELECTRICAL  NODE 
OF  CAL  POLY  MODEL 


O  CONNECT  NODES  NEOUINED  BY  ICES  IN 
ONOEN  TO  DEFME  WHERE  -  JOINS*  ARE 
IMPLEMENTED 


//////////.  IGES  FLOW  ASSOCIATIVITIES  AT 
THE  LOWER  LEVEL  NETWORK 
SUBFIGURE 


ICES  FLOW  ASSOCIATIVITIES  AT 
THE  HIGHER  LEVEL  NETWORK 
SUBFIGURE 


Figure  A2-1 
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ISSUE  # 

1.  3/18/87 

ISSUE:  CONNECTIVITY 
DISCUSSION: 

Connectivity  has  been  examined.  It  was  determined  that  more  than  one  entity  would  be  needed  to 
capture  the  functional  interconnections  in  a  PWB.  Functionality  must  be  separated  trom  physical 
implementations  and  entity  definitions  should  be  explicit  in  this  respect.  There  is  a  need  to  consider 
logical  (functional)  connectivity  separately  trom  physical  connectivity. 

RESOLUTION: 

The  issue  is  partially  resolved  as  of  2/4/87. 

We  have  separated  functional  (logical)  connectivity  trom  physical  connectivity.  An  instance  of 
functional  connectivity  is  modeled  as  a  Required  Electrical  Network  (Renamed  Defined  Electrical 
Logical  Link). 

We  have  not  yet  established  a  particular  model  of  the  physical  connectivity.  We  have  tentatively 
adopted  a  concept  of  Path  to  represent  a  physical  connectivity.  We  think  that  Paths  may  be 
composed  of  Sub  Paths  with  Physical  interfaces.  The  model  will  map  the  functional  connectivity 
onto  the  physical  connectivity  by  associative  entities  relating  Required  Electrical  Networks  to  Paths. 

2.  1/20/87 

ISSUE:  ELECTRICAL  AND  ELECTRONIC  REFERENCE  DESIGNATORS 
DISCUSSION- 

There  is  a  lot  of  discussion  possible  about  these  and  how  they  are  used. 

3.  1/20/87 

ISSUE:  SUBSTITUTE  AND  ALTERNATE  PARTS 

DISCUSSION; 

SUBSTTTUTE_PART  is  found  in  Source  Document  #2  (Westinghouse  PWA  Study).  The 
possibility  exists  of  more  than  one  substitute  part  for  an  item  on  a  parts  list.  Substitute  pans  are  also 
program  dependent. 

Substitute  part  and  Alternate  Part  are  similar  ideas,  but  there  appears  to  be  some  distinction 
between  them.  The  Mechanical  Products  team  in  Peoria  have  some  ideas  on  these. 
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Parts  that  are  components  on  higher  assemblies  must  otter,  be  submitted  for  approval  from  :he 
customer.  Alternate  parts,  superseded  pans,  and  substitute  parts  must  be  submitted  to  various 
authorities  for  approval.  It  is  not  clear  what  the  aefinitions  of  each  of  these  terms  should  be. 

4.  (Combined  with  issue  #3) 

5.  1/21/87 

IRRUC-  fill  pattern 

DISCUSSION 

Graphical  Entities  from  the  UK  EDIF  Support  Document  such  as  Fill  Pattern  need  to  be  understood 
to  see  if  they  represent  conceptual  data  required  in  our  model.  It  was  also  suggested  that  graphical 
characteristics  such  as  fill  color  were  actually  representations  of  other  meanings  which  should  be 
discovered. 


6.  1/21/87 

ISSUE:  SIGNAL  ARRAY 
DISCUSSION: 

Signal  Array  from  the  UK  EDIF  Support  document  needs  clarification.  Our  interpretation  is  that  it 
represents  a  set  of  'signals’  that  may  be  carried  on  an  instance  of  ELECTRICAL_NETWORK.  Other 
entities  that  may  require  clarification  are  those  associated  with  INSTANCE  and  PATH. 

RESOLUTION 

Signal  Array  has  been  deleted  from  EDIF  200.  This  issue  is  closed. 


7.  1/21/87 


ISSUE:  PRODUCT  DEFINITION  DOCUMENT 

DISCUSSION 

The  definition  for  the  conceptual  entity  Product_Definftion_Document  needs  clarification.  There 
are  many  source  elements,  some  of  which  may  be  out  of  scope  anyway,  which  may  be  mapped  into 
this  conceptual  entity. 
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8.  1/26/87 

ISSUE:  GROUND 
DISCUSSION: 

From  a  functional  standpoint,  Ground  seems  to  be  a  Node  rather  than  an  Electrical  Network. 
Electrical  designers  freauently  designate  more  than  one  Ground,  (e.g.  Signal  Ground.  Power 
Ground,  etc.)  These  serve  to  identify  requirements  that  these  nooes  are  references  for  different 
collections  of  functions  and  that  the  physical  designer  is  to  keep  these  distinct  and  avoid  'ground 
loops". 

3/18/87 

There  is  a  developing  belief  that  Ground  is  more  likely  to  be  a  special  kind  of  signal. 

9.  1/26/87 
ISSUE:  POWER 
DISCUSSION: 

Power  (B+)  seems  to  be  another  Node  idea  like  Ground. 

3/18/87 

Power  seems  also  to  be  a  kind  of  signal. 

10.  2/4/87 

ISSUE:  OWNERSHIP  OF  SHAPE/SIZE 

DISG-USSIPN; 

The  Shape/Size  entity  recognizes  the  existence  of  defintions  of  dimensions  and  tolerances  for 
items  which  apply  to  more  than  one  Item.  That  is,  there  are  many  difterent  part  numbers  with  the 
same  shape,  size  and  tolerances.  An  example  of  this  is  resistors  where  there  are  over  30.000 
different  MIL  Standard  part  numbers  for  just  1/4  Watt  metal  film  resistors  with  the  same  shape,  size 
and  tolerances. 

The  existence  of  a  multiple  use  Shape/Size  brings  up  the  need  to  identify  whose  Shape/Size  it  is. 
That  is,  there  is  an  owner  of  the  definition  who  must  be  associated  with  it  In  the  case  of  industry  , 
National  or  International  Standards,  there  is  a  custodian  of  the  Standard  who  is  the  owner.  In  the 
case  of  sharing  of  data  among  different  enterprises,  a  Shape/Size  must  be  identified  with  the 
enterprise  who  owns  1 
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11.  2/6/87 

ISSUE:  HOW  SHOULD  ENVIRONMENTAL  REQUIREMENTS  BE  MODELED? 

DISCUSSION: 

In  VHOL,  ambient  temperature  is  introduced  as  a  requirement  through  a  "PORT.  The  VHDL 
solution  may  work  well  within  their  specific  application  but  we  need  to  consider  a  more  general 
solution  which  accomodates  all  environmental  constraints. 


12.  2/10/87 

ISSUE:  UNIQUENESS  OF  PART  NUMBERS.  •  COULD  THERE  BE  DUPLICATE  PART 

NUMBERS  WITHIN  AN  ORGANIZATION? 

DISCUSSION: 

Some  task  team  members  believe  that  the  answer  is  yes,  depending  on  the  level  of  design.  This  is 
something  that  needs  to  be  tested.  A  variety  of  different  enterprises  should  be  asked.  There  has 
long  been  a  belief  in  many  places  that  the  combination  of  the  owning  enterprise  identification  and  its 
part  number  is  unique. 


13.  2/10/87 

ISSUE:  FUNCTIONAL  UNITS  VERSUS  IMPLEMENTATIONS 

DISCUSSION: 

A  functional  unit  may  have  1  implementation  (1  design)  but  2  distinct  functional  interfaces.  The 
behavior  is  the  same  in  both  cases,  but  the  description  of  the  behavior  is  different.  An  example  of 
this  is  the  part  74LS138  which  may  be  used  as  a  binary/decimal  decoder  or  a  demultiplexer.  Are  the 
binary/decimal  decoder  and  demultiplexer  different  functional  units  which  may  be  implemented  by 
the  same  physical  design? 

BESQLimON; 

See  issue  16  and  Appendix  A4  items  15, 16,  and  17 

14.  2/10/87 

ISSUE:  SIGNAL  BUNDLES/BUSSES 
DISCUSSION: 

A  bundle  of  signals,  a  bus,  is  a  notational  and  graphical  convenience  lor  schematics.  The 
connectivity  expressed  via  a  bus  construct  can  be  expressed  using  the  concepts  of  the  electrical 
network  (Renamed  Defined  Electrical  Logical  Link). 


During  high-level  design,  a  bus  may  be  defined  without  specifying  its  width.  Can  this  be  handled 
with  the  electrical  network  concept? 
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15.  2/10/87 

ISSUE:  CONSTANT  FUNCTIONS 
DISCUSSION: 

A  constant  function  is  a  functional  unit  whose  output  is  always  the  same,  regardless  of  the  inputs. 
There  are  familiar  examples  such  as  voltage  regulators  whose  purpose  is  to  flatten  out  variations  of 
input  into  unvarying  output. 

There  are  also  some  times  when  digital  devices  are  involved  when  there  seem  to  be  needs  for  an 
idea  of  unchanged  output  The  examples  of  this  seem  to  be  issues  involving  simulation  ideas  and 
the  description  seems  to  be  talking  in  ‘Green  Stuff: 

a)  allowing  0  input  states  which  results  in  1  output  (all  inputs  are  ‘donl  care’  by  default),  or 

b)  introducing  the  notion  of  ‘donl  care"  signals. 


16.  2/18/87 

ISSUE:  SEPARATION  OF  DEMAND  REQUIREMENTS  FROM  DESIGN  SOLUTIONS 

DISCUSSION; 

As  a  result  of  proposals  in  PDES,  the  PDES  Product  Oata  Planning  Model  has  separated  the  ideas 
of  functional  characteristics  data  from  physical  characteristics  data. 

In  the  Cal  Poly  modeling,  there  were  discussions  and  diagrams  drawn  which  included  such  ideas  as 
a  -Logic  Diagram"  and  truth  tables  (expressed  in  Ts  and  F's  or  0‘s  and  1  ’s)  being  part  of  the  oesign 
of  some  systems.  A  question  was  raised  about  where  data  of  this  sort  fits  in  the  model. 

There  is  a  view  that  the  "Logic  Diagram"  and  the  T-and-F  or  0-and-1  Truth  Tables  are  a  form  of 
demand  requirements  at  a  fairly  detailed  level.  A  Truth  Table  represents  a  requirement  for  logic 
which  may  be  satisfied  by  more  than  one  technological  solution.  For  example,  logic  can  be 
implemented  by  fluidics  or  electronics.  In  electronics  we  have  various  solutions  to  choose  from 
such  as  ECL  and  TTL 

When  a  specific  solution  technology  is  chosen,  then  the  characteristics  of  the  design  solution  must 
be  expressed  in  terms  of  the  units  of  the  chosen  technology.  For  example,  if  the  chosen  solution  is 
electronic,  the  characteristics  become  expressed  in  transistors,  resistors,  capacitors,  etc.  and  their 
details  in  ohms,  volts,  amperes,  etc. 

RESOLUTION; 

We  have  recognized  three  separate  structures  rather  than  two.  The  first  structure  is  the  breakdown 
of  demand  requirements.  Then  there  is  a  structure  of  definition  of  functional  characteristics.  This 
second  structure  is  defined  in  terms  of  a  chosen  technology.  The  third  structure  is  the  breakdown 
of  the  physical  characteristics  of  the  design  solution  to  the  requirements.  Between  any  two  of  these 
structures,  it  is  unlikely  that  there  will  be  a  one-to-one  map  between  the  units. 
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A  FEO  was  developed  at  Cal  Poly  to  illustrate  the  three  structures.  Because  the  structures  were 
each  drawn  in  a  difterent  color,  thay  became  referred  to  as  "green  stuff",  "blue  stuff"  and  "red  stuff. 
The  figure  below  is  this  FEO. 
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17.  3/12/87 

ISSUE:  FEEDBACK 
DISCUSSION: 

There  are  cases  where  an  output  signal  depends  not  only  on  some  present  state,  but  on  some  prior 
state  or  condition  as  well.  The  model  at  this  time  will  not  satisfy  this. 

18.  3/11/87 

ISSUE:  DELAY/TtME  BASED  PHENOMENA 

DISCUSSION: 

The  model  needs  to  provide  for  signal  relationships  which  vary  by  defined  freauency,  time,  phase, 
etc. 

19.  3/12/87 

ISSUE:  ORDERED  SETS  OF  SIGNALS 

DISCUSSION: 

The  model  needs  to  provide  for  relationships  of  ordered  sets  of  signals. 

20.  3/12/87 

ISSUE:  NON-VOLTAGE  SIGNALS 
DISCUSSION: 

Marry  elctrical  units  have  inputs  and/or  outputs  which  are  not  voltage.  Some  signals  seem  to  be 
physical  motion  (e.g.,  the  movement  of  the  toggle  on  a  switch,  the  rotation  of  a  motor  armature)  or 
radiation  (e.g.  the  light  from  a  flashlight,  infrared  from  an  electric  heater,  etc.). 

21.  3/12/87 

ISSUE:  ANALOG  AND  PERIODICALLY  REPEATING  SIGNALS 

DISCUSSION: 

The  model  should  provide  a  means  for  expressing  signals  such  as  sine  waves  or  repeating  sawtooth 
voltages. 
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22.  3/25/87 

ISSUE:  SHOULD  SIGNALS  BE  DEFINED  ON  BOTH  PORTS  AND  NODES? 

DISCUSSION: 

There  was  considerable  discussion  on  this.  Ports  are  defined  as  the  logical  places  where  functions 
of  a  functional  unit  are  accessed.  The  common  view  is  that  the  original  designer  establishes  the 
ports  of  the  functional  unit  when  he  designs  it  Normally  these  are  the  places  which  are  involved 
with  the  functional  connection  of  the  functional  unit  to  some  other  functional  unit 

It  is  also  not  unusual  for  someone  deciding  how  to  test  units  in  production,  or  in  service,  will  decide 
that  it  will  be  necessary  to  define  ‘signals'  at  places  within  the  networxs  of  the  functional  unit  which 
were  not  defined  as  ports  by  the  original  designer.  It  is  believed  that  persons  doing  this  are  also 
defining  ports.  These  lest  points'  seem  to  satisfy  the  definition  of  'Port'.  Not  all  ports  are  defined 
at  the  time  of  first  design. 

23.  3/25/87 

ISSUE:  ARE  THERE  SIGNALS  WHICH  ARE  "ONE  PORT*  SIGNALS? 

DISCUSSION: 

When  discussing  signals,  we  explored  various  different  kinds  of  signals  which  might  be  involved  in 
describing  the  behavior  of  functional  units.  Some  things  within  the  scope  of  electrical  products  are 
energy  converters  or  electro-mechanical  units.  These  give  rise  to  ‘signals'  which  are  in  the  form  of 
radiation  (e.g.,  the  light  from  a  flashlight,  heat  from  an  electric  heater,  the  infra-red  signal  rrom  the  TV 
remote  controller),  physical  force  (e.g.,  the  shaft  torque  of  an  electric  motor),  etc. 

Are  there  two  ports  involved  in  the  "light"  signal  from  the  flashlight,  or  only  one? 
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GENERAL 

This  appendix  is  provided  as  documentation  of  the  discussions  during  the  development  ot  the  model.  It  is 
included  so  that  readers  may  have  some  sense  of  the  arguments  and  analyses  which  took  place.  Net  ail  of 
the  opinions  captured  were  unanimous  or  even  consensus  views.  Some  still  represent  strong 
differences  of  opinion. 


1.  PDES  PLANNING  MODEL  The  POES  planning  model  is  a  management  tool.  It  defines  the  scope 
of  product  data,  thereby  Describing  the  scope  of  PDES.  It  is  used  to  establish  the  context  for  the 
detailed,  refined  conceptual  models.  With  the  PDES  planning  model  it  is  possible  to  see  aspects  of 
conceptual  product  data  which  cross  all  disciplines  such  as  the  bill  of  materials. 


2.  CONCEPTUAL  DATA.  A  conceptual  data  model  talks  about  data:  it  contains  the  fundamental  data 
elements  of  an  enterprise.  Fundamental  data  elements  are  combined  to  create  compounds.  These 
compounds  constitute  the  external  views.  The  procedures  for  creating  the  compounds  are  unioue 
recipes  or  instructions  for  manipulating  elementary  data.  These  procedures  are  unique  entities  in 
their  own  right  Are  these  recipes  part  of  the  conceptual  data  model?  No. 

The  conceptual  data  model  captures  the  meaning  and  relational  integrity  rules  for  data  of  an 
enterprise.  It  does  so  in  a  way  that  makes  it  independent  from  the  uses  of  the  data  for  information 
and  the  manner  of  physical  storage  of  the  data.  Much  of  the  data  we  are  accustomed  to  using  as 
people  is  presented  to  us  in  a  form  of  symbols  to  which  we  have  attached  meaning.  An  example  of 
this  is  the  familiar  notation  of  music.  The  sheet  music  presents  a  complex  set  ot  symbols  designed 
tor  human  comprehension.  The  fines  and  spaces  of  the  treble  clef  actually  stand  for  a  musical  scale 
of  predefined  tones  or  audible  frequencies.  The  open  and  filled  ellipses  of  notes  with  their  attacned 
lines  are  symbols  conveying  tone  and  duration  to  humans.  It  is  the  meanings  of  the  musical 
symbology  which  are  the  domain  of  conceptual  data  modeling. 

The  conceptual  data  model  does  not  tell  one  how  to  arrive  at  the  data.  Rather  it  depicts  the 
relationships  among  the  fundamental  data  items  of  the  enterprise.  For  instance,  a  conceptual  model 
does  not  contain  the  rules/procedures  necessary  to  create  a  schematic  (an  external  view  of  the  raw 
data)  although  it  does  contain  all  of  the  data  elements  (and  their  interrelationships)  necessary  to 
construct  this  external  presentation  view  of  the  functionality  of  the  circuit.  The  rules  for  deriving 
external  views  are  user-specific.  The  proper  place  for  these  rules  might  be  the  external  schema. 

We  tend  to  get  into  arguments  over  what  is  conceptual  data.  This  is  to  some  degree  because  there 
are  a  number  of  different  concepts  of  our  enterprises  which  various  disciplines  are  trying  to  model. 
We  need  to  separate  those  concepts  which  are  different  from  each  other  and  give  them  different 
names.  The  developing  world  of  Artificial  Intelligence  (AO  is  where  some  of  these  come  to  light.  Al  is 
concerned  with  the  meanings  and  referential  integrity  rules  which  we  are  modeling  in  the  conceptual 
data  model.  They  are  also  concerned  with  other  kinds  of  rules  that  the  enterprise  has  established. 
Some  of  those  rules  are  for  manipulating  the  fundamental  data  to  derive  information  for  specific 
purposes.  Some  of  those  rules  are  the  knowledge  of  how  cenain  activities  of  the  enterpnse  are 
performed  which  result  in  the  creation  of  values  of  the  conceptual  data.  We  should  not  confuse  the 
conceptual  data  with  the  rules  tor  its  use  or  creation. 
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3.  A  CONCEPTUAL  DATA  MODEL  PQR  ELECTRICAUELECTRQNIC  DATA.  An  electrical/eiectronic 
product  (e/e)  is  a  product  when  makes  use  of.  transmits,  or  generates  electricity.  A  product  is  a 
concept  of  goods,  not  services,  sold.  A  conceptual  data  moael  tor  e/e  products,  using  diagrams  and 
text,  depicts  the  entities,  relationships,  and  attributes  describing  the  fundamental  data  which  defines 
the  products  over  their  life  cycle.  The  present  team  scope  is  a  limited  subset  of  the  total. 

The  current  detailed  conceptual  model  for  e/e  product  data  will  contain  the  data  that  defines  the 
functional  characteristics  and  the  physical  realization  of  an  e/e  product  based  on  a  specified 
technology. 

The  data  which  will  be  captured  by  this  model  is  expressed  in  the  units  of  a  particular  technology  and 
concerns  the  notions  of  connectivity  stn  injure  behavior  oloctnoai  nropopiog  and  pnv«ncal 

solutions. 


a)  CONNECT! VITY:  An  electrical  circuit  is  composed  of  functional  units  connected  together. 
Connectivity  is  expressed  via  logical  or  physical  networks.  A  logical  network  is  a  collection  of 
functional  unit  nodes  (may  include  one  port)  which  are  declared  to  be  electrically  equivalent. 
Electrical  connectivity  can  be  expressed  logically  (i.e.  the  circuit  design  on  a  schematic),  or 
physically,  via  the  actual  implementation  of  the  logical  idea  (i.e.,  wire  conductors,  copper  paths  on 
a  PWB,  etc.). 

b)  STRUCTURE:  Electrical  products  are  assemblies  of  functional  units  from  primitives  up  through 
appropriate  levels  of  aggregates.  This  is  parallel  to  physical  assemblies.  The  mapping,  however, 
is  not  one-to-one  (4  functional  gates  may  be  in  one  physical  package).  With  respect  to  the  initial 
requirements  which  drive  the  functional  realization,  the  notion  of  hierarchical  structure  penams 
but  is  not  yet  fully  understood.  Once  again,  there  is  some  kind  of  mapping  between  the  initial 
requirements  breakdown,  and  the  functional  definition  breakdown. 

c)  BEHAVIOR:  The  behavior  is  the  description  of  the  functionality  in  the  unit.  There  seem  to  be  two 
kinds  of  functions.  Some  units,  such  as  resistors  and  capacitors,  usually  are  thought  of  as  having 
•passive'  characteristics  even  though  those  charactenstics  are  subject  to  change  from  such 
stresses  as  applied  voltage  or  temperature.  Other  units  such  as  transistors  are  thought  of  as 
having  "dynamic"  characteristics.  There  is  an  additional  complication  in  that  some  electrical  units 
are  "energy  converters"  so  that  their  behavior  involves  other  than  purely  electrical  values.  A 
flashlight,  tor  example,  has  a  physical  force  input  to  turn  it  on  or  off  and  an  output  of  light  and  some 
heat. 


i.  ELECTRICAL  PROPERTIES:  These  are  the  static,  or  passive,  constraints  on  the  behavior  of 
a  functional  unit  These  constraints  cannot  be  derived.  Examples  include  resistance, 
capicrtance,  and  inductance. 

5.  DYNAMIC  CHARACTERISTICS:  Some  of  these  can  be  recognized  as  being  described  by 
relating  signals  applied  as  inputs  to  signals  which  appear  as  outputs.  Some  of  these 
relationships  become  quite  complex  where  an  output  depends  not  only  on  some  present 
input  state  but  on  some  prior  condition  as  well. 

i.  NON-ELECTRICAL  CHARACTERISTICS:  The  team  has  made  no  attempt  to  model  data  tor 
these  kinds  of  characteristics.  We  can  conjecture  a  little  about  the  description  of  such  simple 
units  as  a  toggle  switch  where  the  electrical  characteristic  is  dependent  upon  the  position  of 
some  movable  physical  geometry. 
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4,  E'E  mNDEPTUAL  MODEL  SCOPE.  There  are  four  clusters  of  entities  within  the  PDES  PLANNING 
MODEL  which  have  counterparts  in  the  e/e  conceptual  data  mooel. 

Fl  INCHON  AL  UNIT  FNTTT1ES:  Functional  Unit,  Required  Functional  Subunit  Occurrence, 

Functional  Interface  Requirement,  Required  Functional  Characteristic. 

SHAPE'SIZE  ENTITIES: 

Shape/Size  Specification,  Shape/Size  element  specification,  Shape/Size  Tolerance  Requirement. 
PHYSICAL  DESIGN  ENTTIES: 

Physically-Defined  Product  Item.  Required  Physical  Characteristics,  Physically- Defined  Constituent 
Product  Item  Occurrence,  Physical  Interface  Requirement. 

PRODUCT DRERNmON  DOCUMENT  FNTrTIES-  Product  Definition  Document,  Product  Definition 
Document  Version,  Invoked  Product  Definition  Document. 

The  boundary  entities  are  those  entities  immediately  outside  the  scope  of  the  model.  They  include 
t echnolcov-indeoendent  Specified  Demand  entities  and  Manufacturing  pfocess  entities 
(purchasing,  quality  assurance,  etc.) 


5.  FUNCTIONAL/PHYSICAL  CHARACTERISTICS.  We  have  recognized  at  least  two  distinct  aspects  to 
the  conceptual  model  of  eleancal/electronics  data:  FUNCTIONAL  and  PHYSICAL.  The  functionality 
of  a  circuit  is  represented  by  a  top-level  entity,  functional  unit.  The  physical  realization  of  the  circuit  is 
reoreserrted  by  a  top-level  entity,  product  item.  Both  are  hierarchical.  The  decompositional  nature  of 
both  the  functional  unit  and  product  item  is  depicted  by  the  is-has  dual  relationship  to  some  suo-unit 
occurrence  entity. 

Intersection  entities  will  be  necessary  to  depict  the  correspondence  between  the  functionality  of  the 
e/e  product  and  the  physical  realization. 


6.  CONTEXT  ENTITY.  Functional  units  have  unique  identity  within  a  particular  business  context.  This 
suggests  the  need  for  entities  which  provide  a  global  framework  for  uniquely  identifying  functional 
units.  These  entities  will  represent  the  data  which  describes  the  direction  and  boundary  of  the 
design  effort 

Sample  definitions  for  these  entities  indude: 

A.  Information  identifying  a  business  concept  which  serves  as  a  direction  and  boundary  for  design 
efforts.  This  is  of  a  suffdently  abstract  nature  that  it  is  not  in  itself  a  functional  unit  Things  such  as 
’project",  ’program’  are  examples.  Such  a  ’design  context’  distinguishes  design  efforts  from 
each  other. 

C.  The  owner  of  the  name  of  the  thing;  the  perpetrator  of  the  thing.  This  seems  to  be  the 
identification  of  the  owning  ’enterprise". 

The  product  Item  must  fit  in  this  new  structure.  It  will  tie  either  diredly  to  the  enterprise  or  the 
design  context 
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7.  WHAT  IS  THE  IDENTIFICATION  (KEY)  OF  A  FUNCTIONAL  ITEM? 

Functional  Iterms  first  seem  to  appear  in  early  design  stages.  System  engineering  starts  to  break  a 
system  down  into  functional  biock  concepts.  These  concepts  are  given  meaningful  names.  These 
names  are  the  identification  of  the  items.  Examples  are  terms  such  as:  Guidance  Section,  Signal 
Processor,  Decoder,  etc.  This  idea  seems  to  continue  to  considerable  detail  where  we  have 
schematic  symbols  representing  resistor,  capacitor,  transistor,  NAND  Gate,  etc. 

When  we  draw  the  bolck  diagram  or  schematic,  we  create  occurrences  of  the  generic  functional 
items.  In  order  to  distinguish  one  occurrence  from  another,  we  assign  “reference  designations"  (i.e. 
R1.R2,  U12). 

The  functional  names  alone  do  not  seem  to  be  enough.  When  we  design  similar  products,  we  tend 
to  use  similar  generic  names.  Therefore,  we  think  that  the  identification  of  a  Functional  Unit  is  actually 
a  concatenation  of  the  generic  name  with  a  migrated  key  from  an  entity  which  represents  the  product 
being  designed.  This  is  probably  Product  Model.  This  is  an  indication  that  we  probalby  need  to  do 
some  modeling  of  the  Product,  Product  Model,  End  Item  and  End  Item  Unit  ideas. 

8.  WHERE  ARE  THE  REQUIREMENTS? 

[see  also  items  16  and  17] 

In  our  data  planning  model,  everything  about  the  product  is  in  fact  a  specification  or  requirement  until 
SO  aoual  manufactured  uni  appears!  What  is  released  from  design  engineering  to  the  manuf actunng 
process  is  specifications  and  requirements.  What  is  established  by  the  manufactunng  planning 
activity  is  requirements. 

When  a  fabrication  or  assembly  process  produces  hardware,  if  examinations  or  tests  are  performed 
on  the  hardware,  for  the  first  time  actual,  observed  characteristics  come  into  being. 

9.  LOGICAL  vs.  PHYSICAL  NETWORKS. 

More  than  one  logical  (or  functional)  network  may  exist  on  the  same  set  of  physical  connections 
(Path).  An  example  of  this  is  in  waveguide  multiplexers  where  RT/TR  functions  separate  transmitted 
signals  from  received  signals  although  they  share  some  of  the  same  physical  waveguide.  Tri-State 
devices  can  be  involved  in  this  concept 

1 0.  VHDL  SIGNAL  vs  CAL  POLY  MODEL  NETWORK  AND  SIGNAL. 

[Th»  Network  was  renamed  Defined  Electrical  Logical  Link  during  later  modeling  activities] 

We  have  modeled  two  separate  ideas  which  we  have  named  Network  and  Signal.  The  Network  is  a 
name  for  the  idea  of  functional  connections.  Signal  is  a  name  for  a  difference  in  potential  between 
two  Networks  (Revised  to  difference  between  ports).  We  have  an  idea  named  Node  which 
represents  a  place  where  a  function  of  a  Functional  Unit  may  be  accessed.  A  Network  is  a  connected 
set  of  Nodes. 
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VHDl  appears  to  use  Signal  to  represent  what  we  have  called  Network.  For  purposes  ot  simulation, 
in  VHDL  values  (i.e.,  voltages)  can  be  assigned  to  Signals.  Different  values  can  be  assigned  to  the 
same  Signal  name  at  different  times.  VHDL  has  a  concept  of  Port.  VHDL  distinguishes  between 
Formal  Port  and  Actual  Port.  A  Formal  Port  is  an  instance  of  a  place  of  access  to  a  Design  Entity. 
When  a  Design  Entity  is  -instantiated"  (used  in  relation  to  some  other  Design  Entity),  a  Formal  Port 
becomes  an  Actual  Port.  The  Actual  Port  must  be  assigned  a  name  (which  may  be  the  same  as  its 
Formal  Port  name).  The  Formal  Port  seems  to  map  to  our  Defined  Functional  Port  and  the  Actual  Port 
to  out  Electrical  Node. 

As  of  6  February,  we  have  a  concept  that  a  Node  may  be  part  of  more  than  one  Network.  For 
example,  when  tri-state  devices  are  involved,  a  device  is  sometimes  functionally  connected  and 
sometimes  not.  This  means  that  Networks  are  dynamically  defined  depending  upon  the  state  of  the 
devices.  [This  idea  of  a  node  participating  in  more  than  one  network  has  been  rejected  at  all  reviews 
of  the  model]. 

VHDL  contains  the  idea  of  a  Bus.  It  provides  for  a  user-defined,  bus  arbitration  rule  which  will  define 
how  to  determine  what  is  present  on  the  Bus  when  driving  devices  are  in  different  states. 

1 1 .  LOGICAL  NETWORK.  [Note:  Logical  network  was  renamed  Defined  Electrical  Logical  Link]  The  e/e 
conceptual  model  contains  the  concept  of  electrical  network.  To  have  an  electrical  network,  there 
must  be  at  least  one  electrical  network  node  which  demands  at  least  one  electrical  node  which  in  turn 
demands  exactly  one  functional  subunit  occurrence.  An  electrical  network  node  is  an  instance  of  a 
port  which  is  part  of  a  network.  Logically,  one  can  access  the  network  anywhere.  Physically,  one  can 
access  the  netwoik  only  at  a  node. 

The  logical  network  concept  embodied  by  the  model  is  distinct  from  the  physical  concept  of 
connectivity.  A  logical  network  is  a  collection  of  instantiated  nodes  and  at  most  one  port  which  are 
electrically  in  common.  A  signal  is  the  difference  in  potential  between  two  ports.  It  must  be  defined 
with  respect  to  at  least  two  ports.  A  signal  has  a  value  (voltage),  a  measurement  port  and  a  reference 
port. 

"Ground"  is  a  signal  of  some  kind. 

A  node  or  a  port  can  belong  to  only  one  network.  Sub-networks  and  dynamically  re-configured 
assemblies  do  not  fundamentally  describe  different  networks.  Different  subsets  do  not  signify 
unique  nets  in  action. 

A  network  may  contain  at  most  one  port  to  convey  the  boundary  conditions  between  levels.  AD  ports 
connected  to  the  same  network  are  logically  the  same  port.  This  allows  the  model  to  capture  the 
logical  connectivity  correspondence  between  the  internal  design  of  functional  unit  A  and  the 
instantiation  of  functional  unit  A  in  a  higher  unit  design. 
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12.  NETWORK  ANALOGIES. 

TOPOLOGICAL  ANALOGY 

NFT  GUI 

23  T 

FUNCTION  outl  -  int  &  in2 
PORTS  ini,  in2,  outl 


INFORMATION  TRANSFORMATION 

ail 

T 

outl  -I(in1,in2) 

place-holders  in  the  equation  (variables) 


13.  FUNCTIONAL  UNIT.  A  logical  design  of  a  circuit  describes  functions  and  interconnections.  A 
function  has  an  interlace  and  a  design.  The  function's  design  describes  its  subunits  and  the  (internal) 
electrical  interconnections  among  the  subunits.  The  internal  connectivity  is  expressed  in  terms  of 
the  nodes  of  the  subunits  which  are  elecrically  common.  When  the  function  is  pan  of  a  larger  design, 
the  ports  described  by  the  function's  interlace  constitute  the  external  signal  connections  to  the 
internal  network. 

A  nand gate  is  an  example  of  a  functional  unit  The  functional  design  of  the  nand  gate  describes  the 
subunits  which  compose  the  nand  gate.  The  subunits  include  several  instances  of  resistors,  which 
at  the  next  lower  level  are  viewed  as  primitive  functional  units  (a  resistor  cannot  be  further 
decomposed). 

A  primitive  component  may  have  a  functional  design  entity.  Although  it  has  no  sub-units,  its  behavior 
can  be  represented  by  signal  relationships  or  electrical  properties  between  ports. 

The  interface  of  the  nand  gate  defines  the  external  ports.  The  interface  is  the  view  which  describes 
the  functionality  available  at  the  ports.  This  may  be  regarded  as  a  black-box  description  of  the 
behavior  of  the  functional  unit.  A  black-box  description  is  one  in  which  the  internal  transformation  is 
unknown;  only  the  inputs  and  resultant  outputs  and  the  defined  electrical  properties  are  known. 

Ports  are  windows  into  the  functions  of  the  functional  unit.  The  ports  are  not  separate  entities,  they 
are  used  to  make  associations  with  the  internal  functionality. 


14.  MULTIPLE  VIEWS. 

There  is  an  opinion  that  the  model  must  capture  the  the  notion  of  functional  units  with  distinct 
interfaces  but  identical  designs.  A  functional  unit  may  have  one  implementation  (1  design)  but  two 
descriptions  of  what  It  does  (2  interfaces  or  views).  When  this  is  the  case,  the  behavior  of  the 
functional  unit  is  the  same,  but  is  described  in  2  distinct  ways.  An  example  of  this  is  the  74LS138. 
This  functional  unit  may  be  described  as  either  a  binary/decimal  decoder  or  as  a  demultiplexer.  The 
internal  structure  of  the  74LS138  is  identical  whether  it  is  used  as  a  decoder  or  as  a  demultiplexer. 
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There  is  a  differing  opinion  that  the  binary/decimal  decoder  and  the  demultiplexer  are  two  different 
functional  units  which  may  be  satisfied  by  the  same  physical  design.  This  is  a  subtle  but  importantly 
different  idea  from  that  of  multiple  views. 

15.  IRC  CHARACTERIZATIONS.  The  IEC  has  identified  three  distinct  aspects  of  e/e  data: 

Functional  ideaized,  abstracted  behaviors  NAND 

Mechanical  real,  generic  medium  JEDECPKG 

Physical  occurrence  of  the  function  within  a  medium  T1  SN74L300 

There  is  not  a  consensus  among  the  members  of  the  task  team  that  these  three  aspects  are 
required.  From  the  data  model  standpoint,  two  seem  to  be  adequate  to  some  memoers:  these 
would  be  called  functional  and  physical.  The  mapping  between  these  two  would  appear  as 
intersection  entities  in  the  model.  There  is  an  opinion  that  the  IEC  idea  works  backword  from  the 
existence  of  completed  solutions  in  the  form  of  parts.  When  the  data  model  starts  with  the  ideas  of 
required  functional  solution  and  moves  to  designed  physical  solution,  then  it  seems  that  the  two 
aspect  model  appears  and  is  a  more  correct  model.  The  JEDEC  Package  specification  seems  to  fit  as 
a  Shape/Size  definition  within  the  PDES  planning  model. 

The  logical  characterization  deals  with  non-electrical  values  (T,  F,  1,  0).  The  mechanical 
characterization  deals  with  company-specific  manufactured  parts.  An  intermediate  view  which 
expresses  the  abstract  logical  value  in  terms  of  electrical  properties  is  needed. 


Atsfixt  Looks/ 

T 

F 


Electrical 

+5v 

Ov 


This  intermediate  view  must  include  electrical  properties  (delay,  capacitance)  but  should  not  be  tied 
to  a  specific  manufactured  part 


18  Mar  1987 

Subsequent  work  concluded  that  the  T  (true)  and  F  (false)  descriptions  are  "green  stuff"  (see  items 
16  and  17).  That  is,  they  acquirements  not  expressed  in  a  chosen  design  solution  technology  and 
are  out  of  the  present  task  team  scope.  The  "blue  stuff”  of  the  present  scope  seems  very  like  the 
"Intermediate  view"  expressed  above.  It  is  required  to  be  expressed  in  units  of  the  chosen  solution 
technology.  The  Ts  and  Fs  of  "green  stuff"  become  signals  in  volts  in  a  “blue  stuff"  electrical  solution 
technology. 

1 6.  SOLUTIONS  VS.  REQUIREMENTS.  A  solution  at  one  level  becomes  a  requirement  at  the  next  level 
in  the  design  life  cycle.  The  problem  is  that  solutions  must  be  distinguished  from  requirements,  but 
at  what  level?  The  mappings  probably  occur  at  the  lowest  levels.  The  model  must  capture  three 
fundamentally  different  concepts:  requirements  definition,  physical  definition,  and  functional 
definition. 

A  requirement  is  a  statement  of  demand.  Requirements  can  be  decomposed.  They  are 
independent  of  technology. 
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A  functional  unit  is  a  solution,  or  a  statement  of  "what-is",  it  is  an  actuality.  It  is  a  characteristic 
definition.  It  is  defined  behavior.  (Note:  test  vectors  can  be  derived  trom  defined  behavior,  the 
definition  of  test  is  out  of  the  scope  of  the  task  team.) 

A  physical  definition  decribes  the  materials,  dimensions,  tolerances,  etc.  of  the  physical  product. 

17.  DAISY  CHAIN  TRIADS.  The  three  distinct  aspects  which  describe  the  design  data  of  e/e  products 
have  been  designated  green  stuff,  blue  stuff,  and  red  stuff.  Data  may  be  part  of  the  specified 
demand  (green  stuff),  functional  characteristic  definition  (blue  stuff),  or  physical  definition  (red  stuff). 
We  have  limited  the  scope  of  the  initial  model  to  blue  and  red  stuff.  This  is  consistent  with  the  activity 
model  (see  appendix  5).  In  terms  of  the  activity  model,  the  information  flows  decribed  as  the  inputs 
and  outputs  for  the  activities,  Perform  E£  Functional  Desinn.  and  Ppinrm  P'P  Physical  Dasinn 
constitute  the  data  of  blue  and  red  stuff.  The  green  stuff  data  include  all  ol  the  controls  lor  the 
activity.  Perform  ££  Functional  Design. 
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■nwenm  DOOM  SOLUTION 
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Technology 
Design  Requirements 
Approved  Parts  List 
Design  Rules 


Functional  Parts  List 
Functional  Characteristics 
Functional  Connectivity  (Net  List) 


Physical  Parts  List 
Dimensions  and  Tolerances 
Materials 

Physical  interfaces 
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The  most  important  distinction  between  the  green  and  the  blue  worlds  is  that  the  green  data  talks 
about  requirements  independently  of  a  particular  techno lonv  The  blue  data  talks  about  functional 
solutions  to  the  requirements  in  units  gj.  a  specific  tecnnolnnv  For  instance,  a  logic  diagram 
which  has  not  yet  been  expressed  in  terms  of  a  particular  technology  (TIL.  ECL,  etc.)  is  green.  The 
solution  to  the  logic  diagram  which  expresses  the  design  using  a  particular  technology  (hydraulics, 
etc)  is  blue.  A  semiconductor  solution  would  require  the  expression  of  the  logical  Ts  and  F's  or 
Zeros  and  Ones  as  electrical  volts. 

Each  of  these  domains  is  represented  by  the  conceptual  model  with  a  high-level  entity.  Each 
high-level  entity  has  a  corresponding  ts-has  relationship  with  a  sub-unit  entity,  and  with  some 
characteristics  entity.  These  triads  of  entities  will  relate  to  each  other  through  intersection  entities: 
perhaps  at  both  the  high-level  entities  and  the  sub-unit  entities. 
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1 .  ACTIVITY  MODEL  •  DESIGN  ELECTRONIC  AND  ELECTRICAL  PRODUCTS 

This  model  was  developed  by  the  Cal  Poly  Task  Team  as  an  aid  to  understanding  the  scope  and  context 
ot  their  modeling  activity.  The  diagrams  of  the  model  to  one  level  of  decomposition  appear  on  the  pages 
which  follow. 

The  model  illustrates  the  concept  that  design  tends  to  begin  with  functional  design  where  the  major 
functions  are  identified  and  then  broken  down  into  smaller  elements  of  funtionality  until  the  basis  tor  a 
physical  design  is  reached.  The  feedback  paths  show  that  this  is  an  iterative  process.  The  model  also 
shows  that  design  analyses  are  performed  at  both  the  functional  design  level  and  after  a  physical  solution 
is  designed. 

Electronic  and  electrical  products  have  a  wide  range  including  transistor  devices,  printed  wiring  boards, 
wire  harnesses,  electrical  relays  and  switches,  electric  motors  and  generators,  etc.  We  believe  that  this 
general  model  applies  to  the  design  of  all  of  those  kinds  of  products. 

In  its  early  scoping  decisions  the  team  identified  certain  of  the  ICOM’s  of  the  model  as  containing  data 
within  the  task  team  scope  and  others  as  out  ot  scope  as  follows: 

IN  SCOPE 

The  input;  Knowledge  of  part  characteristics'  is  in  scope  to  the  degree  that  it  encompasses  a  library 
of  characteristics  of  parts. 

The  outputs  of  A1  are  within  scope. 

The  outputs  of  A2  are  within  scope.  [These  were  later  determined  to  be  beyond  the  six  week 
schedule  of  the  task  team] 

OUT  OF  SCOPE 

AD  other  ICOMs  were  determined  to  be  out  of  present  scope. 

Particular  note  should  be  taken  of  the  external  controls,  "Technology",  "Design  Requirements", 
"Approved  Parts  List"  and  "Design  Rules"  which  are  out  of  scope. 


2.  A-0  THE  CONTEXT  -  DESIGN  ELECTRONIC  AND  ELECTRICAL  PRODUCTS 

The  purpose  of  this  activity  model  is  to  portray  the  fundamental  activities  of  the  design  process. 
The  model  is  used  as  a  scoping  aid  for  data  modeling. 

The  viewpoint  of  this  model  is  that  of  engineers  involved  in  the  design  of  electronic  and  electrical 
products. 
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2.1  AO  -  DECOMPOSITION  OF  •  DESIGN  ELECTRONIC  AND  ELECTRICAL  PRODUCTS 

The  design  process  is  decomposed  into  activities  of  Perform  Electronic  and  Electrical  Functional 
Design,  Perform  Design  Analyses  and  Perform  Electronic  and  Electncal  Physical  Design.  These 
are  described  in  detail  below. 

2.1.1  A1  -  PERFORM  ELECTRONIC  AND  ELECTRICAL  FUNCTIONAL  DESIGN 

This  activity  produces  the  functional  design  of  the  product.  It  usually  precedes  the  physical 
design  although  this  is  not  absolutely  so.  In  any  case,  it  is  an  iterative  process.  The  functional 
design  is  a  description  of  functional  characteristics  and  connectivity  without  physical  solution 
characteristics  such  as  dimensions  and  tolerances  and  package  characteristics. 

This  activity  is  constrained  by  the  controls  of  available  technology  and  design  reauirements.  The 
functional  design  produced  from  this  activity  is  expressed  in  the  terms  and  units  of  a  chosen 
solution  technology. 

Electrical  schematics  are  a  common  presentation  of  functional  design. 

2.1.2  A2  -  PERFORM  DESIGN  ANALYSES 

This  activity  is  where  analysis  of  both  functional  and  physical  designs  is  performed.  These  are 
analyses  executed  on  the  characteristics  specified  by  the  design.  These  are  not  analyses 
performed  from  measurements  of  actual  parts  being  compared  to  the  specified  design 
characteristics. 

2.1 .3  A3  -  PERFORM  ELECTRONIC  AND  ELECTRICAL  PHYSICAL  DESIGN 

In  this  activity,  the  size,  shape,  physical  layout  and  orientation  of  items  are  determined. 
Specification  of  materials  and  other  physical  characteristics  is  part  of  this  process.  Packaging 
decisions  are  made  which  frequently  result  in  combining  more  than  one  functional  unit  into  a 
single  physical  uniL 

3.  DEFINITIONS  FOR  THE  ACTIVITY  MODEL  ICOMs 

3.1  Approved  Parts  List  *  A  list  of  parts  with  known  characteristics  for  which  the  enterprise  has 
established  prior  usage  approvals  and  the  intent  that  they  be  used  repeatedly  in  multiple 
products.  [Most  such  parts  are  purchased  pans] 

3-2  Available  Technology  -  A  set  of  materials,  manufacturing  methods  and  processes  available  within 
the  enterprise,  and  its  preferred  sources,  for  production  of  its  products. 

3.3  Analyzed  Physical  Design  •  A  physical  design  of  a  product,  or  portion  of  a  product,  which  has 
been  determined  to  satisfy  the  design  requirements  through  design  analysis. 

3.4  Design  Requirements  -  A  collection  of  parameters  which  the  product  must  satisfy.  These 
requirements  include  the  initial  requirements  and  changes  which  occur  over  the  product  life. 

3.5  Design  Rules  -  Policies,  procedures  and  specific  practices  within  the  ertterpnse  which  establish 
constraints  on  how  designs  are  to  be  implemented  and  expressed. 
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3.6  Functional  Connectivity  •  The  data  which  specifies  the  manner  in  which  the  functional  units  are  to 
be  logically  connected  to  lorm  functional  assemblies. 

3.7  Functional  Parts  List  and  Characteristic  Requirements  -  The  data  which  identifies  the  functional 
units  and  their  specified  functional  characteristics. 

3.8  Knowledge  of  Part  Characteristics  -  Any  knowledge  related  to  the  functional  and  physical 
characteristics  of  pre- defined  electronic  and  electrical  parts.  This  is  knowledge  typically  found  in 
manufactureres  data  books  and  enterprise  standard  parts  manuals.  It  is  data  about  the  pans 
independent  of  specific  uses. 

3.9  Knowledge  of  Product  Design  •  This  is  knowledge  which  complements  the  knowledge  of  part 
characteristics.  It  is  knowledge  of  ways  of  assembling  parts  into  products  which  have  proven 
successful.  Unfortunately,  other  than  the  design  rules,  most  of  this  is  not  documented. 

3.10  Physical  Design  -  The  specification  of  the  physical  characteristics  and  constraints  of  a  particular 
electronic  or  electrical  product.  Includes  dimensions  and  tolerances,  material  specifications, 
manner  of  joining  pans,  etc. 

3.1 1  Requirements  for  Functional  Design  Changes  -  These  are  requirements  resulting  from  analyses 
of  the  functional  or  physical  design  which  determine  that  the  design  will  not  satisfy  all  of  the 
controlling  reauirements.  Some  of  these  requirements  for  change  result  from  the  physical  design 
process  which  determines  that  the  functional  design  cannot  be  implemented  within  the 
technology  constraints  or  rules  and  practices  of  the  enterprise. 

3.12  Requirements  tor  Physical  Design  -  Results  from  design  analyses  which  set  specific  constraints 
upon  the  initial  physical  design  to  assure  the  functional  characteristics  are  met 

3.1 3  Requirements  for  Physical  Design  Changes  -  That  part  of  the  results  of  design  analyses  which 
identifies  the  needs  tor  changes  to  an  existing  physical  design. 

3.14  Validated  Functional  Design  -  A  functional  design  of  a  product  whose  performance  has  been 
determined  by  analyses  to  satisfy  the  design  requirements. 
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THE  CAL  POLY  TASK  TEAM  PARTICIPANTS 


Name 

ON-SITE  PARTICIPANTS 

M.  L  Brei  -  Chairperson 

Richard  Brooks 

Dr.  David  Chalmers 

Roger  Gale 

George  Goldsmith 

Kazuo  Hori 

Jerry  Kane 

Andrew  Moulton 

Paul  Nelson 

Curtis  Parks 

John  Rychlewski 

Tom  Smith 

Kurt  Van  Ness 


Affiliation 


BITE,  Inc. 

McDonnell  Douglas 
STC,  Ltd. :  UK 
D.  Appleton  Co..  Inc 
McDonnell  Douglas 
McDonnell  Douglas 
Westinghouse 
Viewlogic  Systems 
Hughes  Aircraft 
General  Dynamics 
McDonnel  Douglas 
Digital  Eouipment  Corp. 
General  Dynamics 


Phone 


(702)  361-7050 

(714)  896-3819 

011-44-279-29531  X2150 

(213)  546-7575 

(714)  896-1712 

(714)  896-1454 

(301)  765-3394 

(617)  480-0881 

(714)  732-5008 

(714)  868-4923 

(314)  223-4235 

(617)  685-1046 

(714)  868-6267 


CONTRIBUTORS  BY  TELEPHONE 


Bert  Gibbons 
Erich  Marschner 
John  Zimmerman 


Westingnouse 

CAD  Language  Systems 

Allied  Bendix 


(412)  778-5435 
(301)  424-9445 
(816)  997-2932 


ASSISTANCE 

Dr.  Richard  Cockrum 
Lt.  Erich  Gunther 
Marcia  I  an  none 
Christine  Mudgett 
Jim  Nell 

Larry  O'Connell 
Alex  Rawling 
Dr.  Charles  Savage 
Jim  Savage 


Cal  Poly  ECE  Dept 

(714)  869-2510 

Wright  Aeronautical  Labs 

(513)  255-6976 

Cal  Poly  ECE  Dept 

(714)  869-2511 

Digital  Equipment  Corp. 

(617)  689-H03 

Westinghouse 

(301)  993-5856 

Sandia  National  Labs 

(505)  844-1061 

Computervision 

(617)  275-1800  x641l 

D.  Appleton  Co.,  Inc. 

(617)  431-7207 

D.  Appleton  Co.,  Inc. 

(213)  546-7575 
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LIST  OF  ATTENDEES  AT  MODEL  REVIEWS 

B  -  Boston  Area 
P  -  Pomona,  Cal  Poly 

W  -  West  Palm  Beach  (ISO/PDES/IGES  Mtg) 
D  -  Dayton 


Name 

Affiliation 

Review 

Ramon  Alonso 

Draper  Labs 

B 

Derec  Anderson 

McDonnell  Douglas  Aircraft 

P 

Lougie  Anderson 

Tektronix 

D 

Mindy  Baden 

Draper  Labs 

B 

Dennis  Bak 

Digital  Eguipmentt  Corp,  Littleton 

B 

Goeff  Blyth 

Marconi  Instruments,  UK 

W 

Michael  Boone 

Naval  Weapons  Center,  Corona 

P 

M.  L  Brei 

Bite,  Inc. 

D 

Don  Buckley 

Harris  Govt  Systems 

B 

Richard  Butler 

Computervision,  Bedford 

B 

Pete  Campbell 

Apiicon,  Inc 

W 

Richard  Cock  rum 

Cal  Poiy  Univ,  ECE  Dept 

P 

Simon  Come 

Univ  of  Leeds,  UK  CADDETC 

w 

Dorothy  Cross 

MITRE  Corp 

B 

Norm  Dietrich 

NCR  Corp 

B 

Don  Dutton 

General  Dynamics,  Pomona 

P 

Mark  Edwards 

Computervision,  Bedford 

B 

Dave  Evans 

General  Dynamics,  DSD 

P 

Larry  Ferguson 

Digital  Equipment  Corp,  Hudson 

B 

Marc  Fletschmann 

Sanders  Assoc. 

B 

Thomas  Furuis 

General  Dynamics,  Pomona 

P 

Jamie  Giusto 

Computervision,  Bedford 

B 

Marshall  Giguere 

Computervision,  Bedford 

B 

Don  Godfrey 

Westinghouse  Corp 

W 

George  Goldsmith 

McDonnell,  Astronautics 

D 

David  Gray 

Computervision,  Hillsboro 

P 

U.  Eric  Gunther 

USAF  AFWAL/MLTC 

D 

Donald  Hall 

Office  of  Sec  of  Defense 

D 

Maureen  Harte 

Rockwell  Irtt. 

P 

Mike  Harden 

Digital  Equipment  Corp,  Tewksbury 

B 

Yosef  Haridin 

Boeing  Electronics 

W 

Steven  Harwin 

Hughes  Aircraft 

D 

Leonard  Hayes 

Institute  for  Defense  Analysis 

P 

Bruce  Hepner 

Giordano  Assoc. 

D 

Kazuo  Hori 

McDonnell,  Astronautics 

P 

Julie  Humpal 

Hewlett  Packard,  Fort  Collins 

W 

Jufie  Irvine 

Hughes  Aircraft 

P 

Richard  Jennings 

CATC 

B 

Susan  Johnson 

Boeing  Electronics 

D 

James  Jones 

Hughes  Aircraft 

D 
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Name  Affiliation  Bgvjew 


Maher  Kailel 

Mrr 

B 

Gerald  Kane 

Westinghouse  Corp 

D 

Mark  Kaufman 

Dynaelectron  Corp 

P 

Sioban  Keane 

GTE.  Govt  Systems 

B 

Richard  Kempf 

Harris  Corp 

D 

Heidi  Kress 

General  Dynamics,  Pomona 

P 

Jim  Kinsley 

Digital  Equipment  Corp,  Andover 

B 

Praticia  Lavigne 

McDonnell  Aircraft 

D 

Lt.  Gene  Leano 

USAF  AFWALJADE  vpo 

D 

Dr.  Robert  Lechner 

Univ  of  Lowell,  Comp  Sci  Dept 

B 

John  Lewis 

USN  FLTAC 

P 

Gene  Lish 

NWC,  Elec  Mfg  Productivity  Fac. 

P 

David  Liu 

Hughes  Aircraft 

P 

Bill  Loye 

Loye  Associates 

W 

Scott  Madsen 

General  Dynamics,  Pomona 

P 

Hany  McBwy 

Hughes  Aircraft 

P 

Robert  Meagher 

Eastman  Kodak 

W 

Jay  Miller 

Cadnetix,  Inc 

w 

Cris  Mudgett 

Digital  Equipment  Corp,  Andover 

B 

David  Nedwek 

General  Dynamics,  Pomona 

P 

James  Ned 

Westinghouse  Corp 

D 

Paul  Nelson 

Hughes,  Ground  Sys 

W 

Cartene  Nightingale 

Hughes  Aircraft 

P 

Larry  O'Connell 

Sandia  Natl  Labs 

BW 

Harish  Patel 

Computer  Sciences  Corp 

P 

John  Payne 

Honeywell 

D 

Milton  Piatok 

Boeing  Electronics 

W 

Michael  Pietrzak 

Solion  Systems 

D 

Paul  PHIa 

McDonnell,  McAir 

W 

Ken  Ray 

NWS.  Seal  Beach 

P 

Gregory  Rivard 

General  Dynamics,  Convair 

P 

John  Rychlewski 

McDonnell,  Astronautics 

D 

MelSaiz 

Harris  Corp 

D 

Donnie  Saunders 

USAF  AFWAL/MLTE 

D 

Doug  Schuithess 

McDonnell,  Douglas 

P 

AJ  Seminatore 

FMC  Corp 

D 

Tom  Smith 

Digital  Equipment  Corp,  Andover 

B 

Dr.  Costas  Spanos 

Digital  Equipment  Corp,  Hudson 

B 

Dick  Sperry 

Digital  Equipment  Corp,  Marlboro 

B 

Brian  Susnock 

DACOM 

B 

Anthony  Testa 

Digital  Equipment  Corp,  Shrewsbury 

B 

Sherwin  Terrill 

NCR  Corp 

B 

Mike  Thompson 

Digital  Equipment  Corp,  Maynard 

B 

Ron  Waxman 

IBM  FSD 

D 

Ronald  Win 

MITRE  Corp 

B 

Charmame  Wtttig 

McDonnell.  McAir 

D 

John  Zimmerman 

Bendix,  Kansas  City  Dlv 

D 
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LIST  OF  DOCUMENTS  AVAILABLE  AS  SOURCES  TO  THE  TASK  TEAM 

Source  #1 : 

From: 

MDAC-St.  Louis 
Subject: 

PDDB  Project  12/86 
Items  Included: 

1 .  PWB  Data  Model-  IDEFl  X  Diagram 

2.  PDDB  -  PWB  Diagram 

3.  Entity  Extended  definitions 

4.  Attribute  Extended  Definitions 

5.  Entity  Relationship  Structure 

6.  PDDB  Attribute  Structure 

Source  #2 
From: 

Westinghouse  Defense  Center  Baltimore 
Subject: 

Printed  Wire  Assembly  (PWA)  Study 

Items  Included: 

1.  To-Be  Data  Modei 

2.  To-Be  Entity  List 

3.  Supporting  Appendices 


Source  <3 
From: 

IGES 

Subject: 

IGES  Electrical  Entities 

Items  Included: 

1 .  Network  Subfigure 
Z  Connect  Point 
3,  Flow  Associativity 
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Source  #4 
From: 

EDIF 

Subject: 

The  UK  EDIF  Support  Project  -  Data  Model  of  EDIF 
EDIF  1  0  0  Specification,  1985 
EDIF  2  0  0  Draft,  12/31/86 

Items  Included: 

1.  EDIF  1  0  0  Glossary 

2.  EDIF  Level  0  Netlist  and  MaskLayout  View  Models 


Source  #5 
From: 

VHDL  72  (five  documents) 

Subject: 

This  is  the  VHSIC  Hardware  Description  Language.  This  is  a  language  which  primarily  captures 
requirements  for  integrated  circuits.  Its  concept  is  that  the  requirements  can  be  described  in  a 
standardized  manner  through  this  language  which  can  then  be  interpreted  by  design  programs 
such  as  Silicon  Compilers. 
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1.  GENERAL 

The  creation  and  operation  of  the  Cal  Poly  Task  Team  provided  some  lessons  for  future  learns  of  this 
type.  These  lessons  are  described  below. 

1.1  PERSONNEL  COMMITMENTS 

The  schedule  for  the  task  team  was  set  in  anticipation  of  the  commitment  of  resources  necessary  to 
execute  the  modeling  task.  The  experience  was  that  the  team  intreouently  had  the  number  of 
source  experts  and  methodology  experts  present  to  reach  the  'critical  mass'  which  is  needed  for 
maximum  productivity  of  such  a  team.  The  model  probably  could  have  been  extended  further  into 
the  data  of  behavior  had  a  more  constant  level  of  expertise  been  present. 

In  the  future,  it  is  suggested  that  plans  for  such  activities  should  be  developed  with  scopes  and 
descriptions  of  resources  required  and  schedules  in  terms  of  weeks  of  effort  after  start.  Actual  dates 
for  execution  should  not  be  established  unless  the  resource  commitments  are  in  hand.  These 
commitments  should  be  from  supervisors  or  managers  who  have  the  authority  to  commit  manhours, 
travel,  and  tacifities. 

1.2  FACILITIES 

To  be  most  effective,  a  modeling  team  needs  certain  kinds  of  facilities  which  are  described  below. 

•  Space  in  which  to  meet  in  group  discussion. 

•  Spaces  in  which  to  divide  nto  smaller  groups  for  discussion. 

•  Large  amounts  of  "blackboard"  space. 

•  Easels  and  tear  off  "flip  chans'. 

•  Wall  space  on  which  to  tape  up  flip  chart  pages. 

•  Ready  access  to  computer  graphics  and  word  processing  tools. 

The  Cal  Poly  Team  had  the  personal  Apple  Macintosh  Computer  of  one  of  the  participants  in  the 
team  room  and  access  to  the  Apple  Macintosh  and  Apple  LaserWriter  in  the  office  at  the  Dean  of 
Engineering.  These  proved  to  be  invaluable  when  attempting  to  maintain  the  documentation  of  the 
project 

The  Apple  Macintosh  seemed  particularly  useful  because  it  was  easy  for  team  members  to  pick  up 
applications  on  it  Its  facilities  for  graphics  and  inserting  graphics  in  word  processing  documents  was 
very  helpful  since  the  products  of  a  data  modeling  team  are  a  mixture  of  graphics  and  text 

This  report  was  prepared  on  the  Apple  Macintosh  and  the  Apple  LaserWriter. 

The  team  did  not  have  sufficient  "blackboard*  space  to  encourage  the  free  flow  of  ideas  when 
modeling. 

There  was  a  complete  wall  available  to  tape  reference  material  on.  This  was  particularly  useful  to 
develop  the  storyboard  for  the  review  presentations. 
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The  Cal  Poly  Team  had  !he  personal  Apple  Macintosh  Computer  of  one  of  the  participants  in  the 
team  room  and  access  to  the  Apple  Macintosh  and  Apple  LaserWriter  in  the  office  of  the  Dean  of 
Engineering.  These  proved  to  be  invaluable  when  attempting  to  matntain  the  documentation  of  the 
project. 

The  Apple  Macintosh  seemed  particularly  useful  because  it  was  easy  for  team  members  to  pick  up 
applications  on  it.  Its  facilities  for  graphics  and  inserting  graphics  in  word  processing  documents  was 
very  helpful  since  the  products  of  a  data  modeling  team  are  a  mixture  of  graphics  and  text. 

This  report  was  prepared  on  the  Apple  Macintosh  and  the  Apple  LaserWriter. 

11  the  team  could  have  had  ready  access  to  one  of  the  JANUS  installations  being  made  available  for 
PDES,  JANUS  would  have  been  used  to  assist  with  testing  and  documenting  the  model. 

The  source  expert  people  that  make  this  kind  of  team  effective  are  the  kind  of  people  that  “cannot  be 
spared".  When  on  home  ground,  such  people  are  frequently  interrupted  for  'important  matters". 
The  University  setting  provided  a  neutral  ground  where  participants  were  spared  from  such 
interruptions. 
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GLOSSARY 


ENTITY  DEFINITIONS 

Defined  Electrical  Logical  Intralink  Constraint 

Data  which  sets  limiting  values  for  a  functional  characteristic,  contained  within  a  single  network,  which 
must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical  connections  are 
implemented.  An  example  might  be  a  length  constraint  in  terms  of  wavelengths  at  a  specified 
operating  frequency. 

Defined  Electrical  Logical  Link 

Data  about  the  logical  electrical  connectivity  within  a  Functional  Unit.  It  establishes  a  set  of  two  or  more 
Electrical  Nodes  or  one  Defined  Functional  Port  and  one  or  more  Electrical  Nodes  as  being  electrically 
in  common. 

Defined  Electrical  Logical  Link  Group 

Data  that  establishes  that  one  or  more  Defined  Electrical  Logical  Links  are  combined  into  a  group  for 
some  purpose. 

Defined  Electrical  Logical  Link  Group  Member 

Data  that  a  Defined  Electrical  Logical  Link  is  a  member  of  a  Defined  Electrical  Logical  Link  Group. 

Defined  Electrical  Logical  Link  Intergroup  Constraint 

Data  which  sets  limiting  values  for  a  functional  characteristic  among  Defined  Electrical  Logical  Link 
Groups  which  must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical 
connections  are  implemented.  Examples  would  be  capacitance  limits  or  an  insulation  resistance 
requirement. 

Defined  Electrical  Property 

Data  about  electrical  characteristics  of  a  Defined  Funtional  Unit  existing  between  two  Defined 
Functional  Ports.  For  example,  resistance,  capacitance  or  inductance  which  are  usually  thought  of  as 
’static*  rather  than  ’dynamic".  (These  properties  do  have  some  variation  such  as  the  temperature 
coefficient  of  resistance  for  a  resistor). 

[Entities  and  attributes  to  capture  the  data  of  these  variations  have  not  yet  been  modeled.) 
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Defined  Electrical  Signal 

Data  used  to  detine  the  behavior  of  a  Defined  Functional  Unit,  expressed  in  terms  of  electrical 
potential  difference  between  two  Defined  Functional  Ports.  (  It  is  through  the  data  which  defines  the 
relationships  of  output  signals  to  input  signal  states  that  dynamic  behavior  of  ’active"  Defined 
Functional  Units  is  captured.  The  characteristic  curves  of  a  transistor  can  be  derived  by  common, 
curve  fitting  algorithms  from  sets  of  these  data.) 

Defined  Functional  Port 

Data  describing  the  logical  accessibility  to  one  of  the  functions  of  a  Defined  Functional  Unit.  (These 
ports  are  what  is  represented  by  lines  or  other  graphic  symbols  identifying  inputs  and  outputs  for 
electrical  devices.  The  port  is  a  characteristic  of  a  Functional  Unit  definition  without  its  having  a  usage. 
The  port  can  be  thought  of  as  a  window  through  which  the  boundary  networks  of  the  functional  unit 
are  seen.  When  a  Defined  Functional  Unit  is  given  an  instance  of  use  (Defined  Functional  Sub  Unit 
Occurrence),  then  the  port  becomes  an  Electrical  Node  of  its  higher  assembly.) 

Defined  Functional  Sub  Unit  Occurrence 

Data  that  a  particular  Defined  Functional  Unit  occurs  as  a  component  of  another  Defined  Functional 
Unit.  There  is  an  instance  of  this  entity  for  each  occurrence  of  a  Defined  Functional  Unit  within  the 
same  higher  level  Defined  Functional  Unit.  This  provides  a  functional  view  of  the  various  levels  of 
component/assembly  product  relationship. 

Defined  Functional  Unit 

Data  about  the  functional,  or  performance,  aspects  of  a  portion  of  a  system.  A  Defined  Functional 
Unit  may  be  a  sub  unit  of  another  Defined  Functional  Unit  and  it  may  have  sub  units  of  its  own. 

Defined  Functional  Unit  Input  State  (a  set  of  stimuli) 

Data  about  conditions  for  a  specific  Functional  Unit.  (Through  the  Defined  Input  State  Signal 
associative  entity,  a  particular  input  state  is  defined  as  consisting  of  one  or  more  Defined  Electncal 
Signals,  in  the  electrical  application.) 

Defined  Functional  Unit  Output  Signal  Related  Input  State 

Data  that  establishes  that  a  Defined  Functional  Unit  Output  Signal  results  from  a  Defined  Functional 
Unit  Input  State. 

Defined  Functional  Unit  Output  Signal 


An  output  signal  of  a  particular  Defined  Functional  Unit. 
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Defined  Functional  Unit  Output  Signal  Propagation  Delay  Specification  (response  time) 

Data  that  a  Functional  Unit  Output  Signal  is  required  to  be  present  within  a  specified  time  after  the 
related  Specified  Functional  Unit  Input  State  has  been  established. 

Defined  Input  State  Signal 

Data  that  establishes  a  particular  Defined  Electrical  Signal  as  being  a  part  of  a  Defined  Functional  Unit 
Input  State. 

Electrical  Logical  Unk  Node 

Data  that  an  Electrical  Node  is  part  of  a  Defined  Electrical  Logical  Link. 

Electrical  Logical  Link  Port 

Data  that  a  Defined  Functional  Port  is  part  of  a  Defined  Electrical  Logical  Link.  Each  Defined 
Functional  Port  can  be  a  member  of  only  one  Defined  Electrical  Logical  Link. 

Electrical  Node 

Data  about  a  logical  (functional)  accessabifify  to  the  functionality  of  a  specific  occurrence  of  a 
Functional  Unit.  This  entity  serves  to  collect  the  Defined  Functional  Port  ID  (e.g.,  Pin  Number) 
together  with  the  reference  label  of  the  occurrence  of  the  Defined  Functional  Sub  Unit  Occurrence 
(e.g.,  U2-Pin  1). 
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ATTRIBUTE  DEFINITIONS 
Defined  Electrical  Property  Name 

The  name  of  a  specific  Electrical  Property  existing  between  two  Ports  of  a  Defined  Functional  Unit. 
These  are  such  names  as  Resistance,  Capacitance,  Inductance,  etc.. 

Defined  Electrical  Property  Units 

Identification  of  the  kind  of  units  in  which  an  Electrical  Property  Value  is  expressed.  Examples  are 
Ohms,  Farads,  etc.. 

Defined  Electrical  Property  Value 

The  value,  or  quantity,  of  an  Electrical  Property 

Delay  Specification 

An  expression  of  a  constraint  of  the  delay  from  the  establishment  of  the  related  Defined  Functional 
Unit  input  State  before  the  Defined  Functional  Unit  Output  Signal  must  be  present.  Most  likely 
expressed  in  time  units. 

[Further  examination  of  this  attribute  will  probably  result  in  additional  attributes  and,  perhaps,  entities.] 
Electrical  Logical  Link  ID 

An  identification  of  an  Electrical  Logical  Link  which  is  unique  within  a  particular  Defined  Functional 
Unit.  May  be  numeric  or  alphabetic. 

Electrical  Logical  Link  Group  ID 

An  identification  of  an  Electrical  Logical  Link  Group  which  is  unique  within  a  particular  Defined 
Functional  Unit  May  be  numeric  or  alphabetic. 

Functional  Unit  ID 

A  unique  identifier  assigned  by  the  enterprise  to  each  Defined  Functional  Unit.  Most  commonly  this  is 
a  meaningful  name.  An  example  might  be  'multiplexer  assembly*. 

[When  the  present  model  is  integrated  into  a  larger  enterprise  or  POES  conceptual  data  model  it  is 
probable  that  a  completely  unique  identification  will  require  a  concatenation  of  several  attributes. 
These  are  likely  to  include  the  identification  of  the  enterprise  which  establishes  (or  owns)  this 
definition  and  a  product  or  model  identification  as  well  as  a  functional  unit  name.] 
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Anmams  pefinitisns 

Input  State  ID 

An  identifier  assigned  by  the  enterprise  to  each  input  signal  state  within  the  definition  of  a  Defined 
Functional  Unit,  Thus,  the  identifier  is  unique  only  within  the  context  of  a  specific  Defined  Functional 
Unit  and  the  combination  of  Functional  Unit  ID  and  Input  State  ID  is  unique  within  the  enterprise. 

Port  ID 

An  identifier  assigned  to  each  Defined  Functional  Port  of  a  Defined  Functional  Unit. 

Signal  ID 

An  identifier  assigned  to  uniquely  distinguish  a  signal,  which  appears  between  the  same  pair  of  ports, 
from  another. 

( If  the  functional  unit  that  is  being  defined  is  a  digital  unit,  then  typical  signals  are  trains  of  digital 
pulses.  These  can  be  most  simply  defined  as  two  signals,  a  high  and  a  low.  Where  the  functional  unit 
is  something  such  as  a  transistor,  there  could  be  many  signals  defined,  each  having  a  different 
voltage  value.) 

Signal  Units 

Identification  of  the  kino  of  units  in  which  the  value  of  the  signal  is  expressed. 

Signal  Value 

A  number  indicating  the  quantity  of  the  units  of  the  particular  signal. 

Sub  Unit  Occurrence  Identification 

An  identification  assigned  to  a  particular  occurrence  of  a  Defined  Functional  Unit  within  another 
Defined  Functional  Unit.  (The  most  common  form  of  this  in  electrical  design  is  a  reference 
designation.  The  same  functional  resistor  used  twice  in  a  higher  unit  might  be  designated  R1  in  one 
occurrence  and  R2  in  the  other.) 
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The  Identification  (key)  of  a  signal  Is  a  concatenation  of  the  Identification  of  the  two  ports  between  which  > 
Is  defined  and  a  signal  10  which  Is  unique  within  the  Defined  Functional  Unit  to  which  the  ports  belong. 


anticipated  that  a  more  complicated  data  model  will  result  with  many  entitles  and  relationships.  However,  II 
Is  expected  that  they  will  stiR  be  related  to  pods  ol  functional  units. 
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BUSINESS  RULES  OF  THE  E/E  CONCEPTUAL  MODEL 


This  section  presents  the  business  rules  of  the  E/E  .conceptual  model  in  English.  The  rules  are  grouped 
by  entities.  Entity  names  are  distinguished  by  bold  italics.  The  number  scheme  below  does  not 
correspond  to  number  schemes  used  in  other  documentation. 

1 .  A  Defined  Functional  Unit  has  0. 1 ,  or  many  Defined  Functional  Unit  input  States. 

2.  A  Defined  Functional  Unit  contains  1 ,  or  many  Defined  Functional  Ports. 

3 .  A  Defined  Functional  Unit  is  0 , 1 ,  or  many  Defined  Functional  Sub  Unit  Occurrences. 

4 .  A  Defined  Functional  Unit  has  0, 1 ,  or  many  Defined  Functional  Sub  Unit  Occurrences. 

5 .  A  Defined  Functional  Unit  contains  0, 1 ,  or  many  Defined  Electrical  Logical  Unte. 

6 .  A  Defined  Functional  Unit  contains  0, 1 ,  or  many  Defined  Electrical  Logical  Link  Groups. 

7.  A  Defined  Functional  Unit  Input  State  is  0,  1.  or  many  Defined  Functional  Unit  Output  Signal 
Related  Input  States. 

8 .  A  Defined  Functional  Unit  Input  State  is  composed  of  1  or  many  Defined  Input  State  Signals. 

9 .  A  Defined  Functional  Port  is  a  reference  port  for  0. 1 ,  or  many  Defined  Electrical  Properties). 

1 0.  A  Defined  Functional  Port  is  a  measurement  port  for  0. 1 ,  or  many  Defined  Electrical  Properties). 

11.  A  Defined  Functional  Port  is  a  reference  port  for  0, 1 ,  or  many  Defined  Electrical  Signals. 

1 2.  A  Defined  Functional  Port  is  a  measurement  port  for  0. 1 ,  or  many  Defined  Electrical  Signals. 

13.  A  Defined  Functional  Port  is  0  or  1  Electrical  Logical  Link  Porte. 

14.  A  Defined  Functional  Port  becomes  0, 1 ,  or  many  Electrical  Nodes. 

15.  A  Defined  Functional  Sub  Unit  Occurrence  contains  1 .  or  many  Electrical  Nodes. 

16.  A  Defined  Electrical  Logical  Link  includes  0  or  1  Electrical  Logical  Link  Porte. 

17.  A  Defined  Electrical  Logical  Link  is  composed  of  1  or  many  Electrical  Logical  Link  Nodes . 

18.  A  Defined  Electrical  Logical  Link  has  0 . 1 .  or  many  Defined  Electrical  Logical  IntraLink  Constrainte. 

19.  A  Defined  Electrical  Logical  Link  is  0. 1  or  many  Defined  Electrical  Logical  Group  Members. 

20.  A  Defined  Electrical  Logical  Link  Group  is  the  1st  logical  link  group  of  0, 1 .  or  many  Electrical  Logical 
Link  Defined  Constrainte. 

21.  A  Defined  Electrical  Logical  Link  Group  is  the  2nd  logical  link  group  of  0,  1,  or  many  Electrical 
Logical  Link  Defined  Constrainte . 

22.  A  Defined  Electrical  Signal  is  0, 1 ,  or  many  Defined  Functional  Unit  Output  Signals. 

23.  A  Defined  Electrical  Signal  is  0, 1 .  or  many  Defined  Input  State  Signate. 

24.  A  Defined  Functional  Unit  Output  Signal  has  0  or  1  Defined  Functional  Unit  Output 
Signal  Propagation  Delay  Definitjons. 

25.  A  Defined  Functional  Unit  Output  Signal  results  from  at  least  1  Defined  Functional  Unit  Output 
Signal  Related  Input  State. 

26.  An  Electrical  Node  is  0  or  1  Electrical  Logical  Link  Nodes. 
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Appendix  F 

PLANS  FOR  THE  AD  HOC  CAL  POLY  EXTENSION  TEAM, 

28  APRIL  1987 


FAX  TO:  George  Goldsmith.  MS  10-1 

McDonnell  Douglas  Astronautics 


FROM:  ML  Brei.  BITE  Inc.  703-361-7050  (fax:  703-361-5904) 
SUBJ:  The  Cal  Poly  Extension  Team 
DATE:  April  28.  1987 


Plans  for  the  Ad  Hoc  Cal  Poly  Extension  Team 


A.  An  ad  hoc  Cal  Poly  Extension  Team  has  been  formed  under  the 
IEEE/DASS  Electronic  Model  Group  (EMG).  This  is  an  intensive, 
concentrated  activity  to  produce  a  usable  conceptual  data  model  for 
the  "actual"  aspects  of  printed  wiring  boards.  This  is  a 
results-oriented  group.  The  model  should  be  complete  by  early  fall 
1987. 

B.  The  team  will  consist  of  experienced  data  modelers  who  are  working 
on  similar  projects  in  their  respective  organisations.  Each  member 
of  the  team  will  bring  copies  of  the  model  he/she  is  working  on  to 
the  modeling  sessions. 

The  following  people  have  been  contacted  to  participate: 


NAME _ 

George  Goldsmith 
McDonnell  Douglas  Astronautics 
5301  Bolsa  Avenue 
Huntington  Beach.  CA  92647 
714-896-1712 

(FAX  896-1315;  verify  896-2323) 

John  Zimmerman 
Bendix  Corporation 
P.0.  Box  419159 
Dept.  883-1 
MS  FB  22 

Kansas  City,  MO  64141-6159 
816-997-2932 


James  Nell 
Westinghouse 
9200  Berger  Road 
Columbia.  MD  21046 


STATUS _ 

Host  for  first  session; 
Is  organising  the  team; 
Session  Administrator 


Session  Facilitator 


PDDI  people  very  interested, 
but  schedule  conflicts  for 
May  4th  session. 
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301-993-5856 


Curtis  Parks 
General  Dynamics 
P.O.  Box  2507,  MS  5024 
Pomono,  CA  91769 
714-868-4923 


Kevin  Blackwell 

Lawerence  Livermore  Laboratory 
415-422-8067 


Leo  Kellett 
Kodak 

716-477-1027 


Paul  Nelson 

Hughes  Aircraft  Company 
Product  Operations  Division 
Bldg.  607,  MS  N323 
PO  Box  3310 
Fullerton.  CA  9634 
714-732-5008 


Susan  Johnston 
Boeing  Aerospace  Company 
P.O.  Box  3999,  MS  9Y-19 
Seattle,  Washington  98124-2499 
206-657-6658 


Bill  Lowe  (?) 


Will  attend. 


Contacted  by  J.  Zimmerman 
Is  interested,  but  might  not 
be  able  to  attend. 


Contacted  by  J.  Zimmerman 
Needs  more  information. 


Needs  to  be  contacted. 


Needs  to  be  contacted. 

(J.  Zimmerman  made  initial 
call) 


Needs  to  be  contacted 
(C.  Parks?) 


Eric  Gunther  Has  information;  Needs  to 

D.S.  Airforce  be  contacted 

AFWAL/MLTC 

WPAFG,  OH  45433 

513-255-6976 


Joan  Tyler  Has  information;  needs  to 

National  Bureau  o  Standards  secure  funding  source. 

Bldg  220  MS  A127 
Gaithersburg  MD  20899 
301-975-6545 

FAX:  975-2128  (verify:  975-3327) 
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Lorna  Estep 

RAMP  Program  Manager 

202-697-4561 


Robert  Megher 
Eastman  Kodak 
Department  672  3-1-EP 
901  Elm  Grove  Road 
Rochester.  New  York  14650 
716-726-4512 


Dr.  Robert  Rolfe 
Harris  Corporation 
P.0.  Box  94000 
Melbourne,  FL  32902 
305-729-5714 


Recommended  by  J.  Tyler: 

Is  out  of  town  until  May  4. 
May  be  interested  in  future 
meetings . 


Has  information:  Will 
know  whether  or  not  he  can 
attend  next  week. 


Has  expressed  interest: 
May  attend  first  day. 


C.  DISCUSSION  TOPICS 

1 .  Modeling  Sessions 

Bring  models  and  other  supporting  material  to  the  sessions 
Meet  once  every  two  months 
Rotate  meeting  sites 

Exchange  information  via  the  IGES  BBS:  301-963-6234:  Cal  Poly 

2.  Domain  of  model 

Printed  wiring  boards  (not  printed  circuit  boards) 
printed  wiring  assemblies? 

Perspective  of  the  model,  OPTIONS: 

1)  Graphics:  physical  layout 

2)  Graphics:  logic  schematic 

3)  abstract  functionality 

4)  actual  printed  wiring  board 

Who  else  is  modeling  the  "actual"  aspects  of  PWB’s? 

3.  Tools 

What  tools  are  available  for  IDEFlx? 

-  IDEF  graphics  editor  for  the  IBM  PC  - 
(Tom  Voegali :  309-578-3244) 

4.  Assignments 


Need  a  list  of  assignments  to  be  completed  prior  to  follow“on 
modeling  sessions. 


Appendix  G 

EXCHANGE  STANDARDS  AND  DATA  MODELING  PROJECT 
PROGRESS  REPORT,  24  APRIL  1987 


TO:  F.  Riddell 

FROM:  ML  Brei 

SUBJ :  FY87  Progress  Report 

DATE:  April  24.  1987 


EXCHANGE  STANDARDS  AND  DATA  MODELING  PROJECT 
PROGRESS  REPORT 


The  goals  of  this  project  are  to  analyze  and  influence  the 
development  of  emerging  CAE  data  exchange  standards  in  support  of 
DoD’s  integration  requirements  for  electronic  product  design 
automation.  To  solve  today’s  integration  problems,  existing  and 
emerging  exchange  standards  must  be  used.  The  effective  use  of 
these  standards  requires  a  precise  understanding  of  the 
interrelationships  among  the  standards.  This  understanding  will 
help  us  determine  the  extent  to  which  the  standards  overlap,  and 
the  areas  where  the  standards  do  not  provide  the  representation 
required. 

Much  progress  has  been  made  toward  the  achievement  of  these  goals. 
First,  we  identified  four  leading  CAE  data  exchange  formats  with 
ambiguous  overlapping  areas:  EDIF,  IGES,  IPC-D-35x,  and  VHDL.  By 
establishing  contacts  with  the  principle  figures  involved  in  the 
development  of  these  formats,  we  have  been  able  to  track  the 
progress  of  each  development  effort.  These  contacts  have  also 
provided  us  with  current  assessments  of  industry’s  views  regarding 
1)  the  current  and  future  viability  of  these  standards,  and  2)  the 
technical  capabilities  of  the  standards. 

We  began  the  investigation  of  the  overlap  issue  with  the 
cooperation  of  the  CALS  OSD  Policy  office.  This  office  is  working 
on  a  structure  to  identify  both  information  requirements  and 
standards  for  the  exchange  of  electronic  product  data.  We  have 
been  participating  in  that  effort  to  the  extent  that  it  applies  to 
the  goals  of  this  project.  To  this  end,  we  helped  organize  a 
landmark  meeting  with  the  leaders  of  EDIF,  IGES,  VHDL,  and  IPC.  At 
this  meeting,  DoD’s  need  for  cooperation  among  the  efforts  to 
minimize  redundancy  was  communicated  to  the  standards  people.  The 
standards  people,  in  turn,  explained  the  philosophies  driving  the 
respective  development  efforts  and  provided  a  historical  perpective 
explaining  why  the  current  situation  exists. 


G-l 


Further  investigation  led  to  the  discovery  of  an  IEEE  effort  (the 
Cal  Poly  Task  Team)  and  the  establishment  of  an  IEEE  DASS  working 
group,  the  Electronic  Model  Group  (EMG).  Both  are  applying  data 
modeling  technologies  to  the  analysis  of  these  standards.  We  are 
active  participants  on  the  Cal  Poly  Task  Team,  and  are  leading  the 
Electronic  Model  Working  Group.  The  Cal  Poly  Task  Team  has 
developed  a  conceptual  model  of  the  structural  information  required 
for  electronic  product  design.  The  purpose  of  this  model  is  to 
identify  and  define  the  primitive  data  involved  in  electronic 
product  design.  This  conceptual  data  representation  may  provide  a 
foundation  for  creating  interfaces  among  disparate  formats  and 
databases.  The  IEEE/DASS  EMG  will  demonstrate  the  technical 
feasibility  of  this  approach. 

We  are  in  the  process  of  organizing  the  IEEE/DASS  EMG  and  will  be 
coordinating  with  users  of  CAE  information  to  test  the  Cal  Poly 
model,  evaluate  data  modeling  methodologies,  and  refine  the  model 
if  appropriate.  The  first  action  of  the  EMG  is  the  formation  of  an 
ad  hoc  modeling  group,  the  Cal  Poly  Extension  Team,  to  produce  a 
model  for  the  physical  aspects  of  printed  wiring  boards. 

The  results  of  the  work  of  the  EMG  will  be  useful  to  all  users  of 
electronic  product  data.  This  includes  CAD/CAE  vendors,  CAD/CAE 
users,  DoD  projects  (such  as  CALS,  TISSS,  and  EIS) ,  and  the 
standards  development  groups . 


TO:  F.  Riddell 

FROM:  ML  Brei 
SUBJ :  FY87  Deliverables 
DATE:  April  21,  1987 


CAE  EXCHANGE  STANDARDS  PROJECT  FY87  DELIVERABLES 


DATE:  TITLE: 


10/08/86  ANSI  Y14.26  Trip  Report 

10/21/86  RAMCAD  TIM  Exchange  Standards  Presentation 

10/16/86  EDIF  Printed  Circuit  Board  Technical  Subcommittee  Trip  Report 

10/27/86  EDIF  Joint  Technical  Committee/Subcommittees  Trip  Report 

10/30/86  NSIA  NBS  Meeting  Report 

On-going  CAE  Exchange  Standards  Status  Reports 
On-going  CAE  Exchange  Standards  Organization  Reports 
11/05/86  UMD  Raracad  Program  Maintenance  Instructions 
UMD  Ramcad  Software  Documentation 
11/10/86  EDIF  User  Group  Trip  Report 

12/17/87  CALS  Information  Requirements  Matrix 

12/17/87  CALS  CAE  Exchange  Standards  Coordination  Meeting  Report 
On-going  CAE  Exchange  Standards  Library  Listing 
01/09/87  Cal  Poly  IDEFlx  Training  Session  Trip  Report 
01/14/87  IGES/PDES  San  Diego  Quarterly  Meeting  Trip  Report 
02/27/87  Cal  Poly  Conceptual  Schema  for  Electronic  Products  Package 
01/30/87  Conceptual  Schema  Demonstration  Project  Plan 
02/02/87  ANSI  Y14.26  Trip  Report 

03/01/87  Design  Automation  Standards  Position  Paper 

02/13/87  Electronic  Product  Case  History  (M.  Melkanoff)  Meeting  Report 
03/12/87  IEEE/DASS  Electronic  Model  Working  Group  Plans 
03/19/87  EDIF  Printed  Circuit  Board  Technical  Subcommittee  Trip  Report 
IDEF0  On-line  Tutorial  (in  progress) 

IDEF0  Modeling  Guidelines  (in  progress) 

04/15/87  Cal  Poly  Conceptual  Schema  Dayton  Review  Report 
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TO: 

FROM: 
SUBJ : 
DATE: 

F.  Riddell 

ML  Brei 

FY87  Meetings  Attended 

April  21,  1987 

DATE: 

LOCATION: 

1-3 

October  86 

Los  Angeles 

7-10 

October  86 

San  Francisco 

15-17 

October  86 

Dallas 

21-22 

October  86 

IDA 

27-28 

October  86 

San  Francisco 

10-11 

November  86 

Santa  Clara 

17 

December  86 

IDA 

05-09 

January  87 

Pomona ,  CA 

12-15 

January  87 

San  Diego ,  CA 

01-04 

February  87 

New  Orleans 

08-27 

February  87 

Pomona ,  CA 

12 

March  87 

Manassas 

19-20 

March  87 

Cupertino ,  CA 

13-15 

March  87 

Dayton,  Ohio 

14 

March  87 

Wright  Patterson 

20 

April  87 

Westinghouse 

21 

April  87 

Harris  Corp. 

22-23 

April  87 

IDA 

MEETING: 


D.  Appleton  Executive  User’s  Forum 
Ansi  Y14.26  Meeting 

EDIF  PCB  Technical  Subcommittee  Meeting 
RAMCAD  TIM 

EDIF  Joint  Technical  Committee /Subcomm. 

EDIF  User’s  Group  Meeting 

EDIF/IGES/IPC /VHDL  Joint  Meeting 

IDEFlx  modeling  training 

IGES/PDES  quarterly  meeting 

Ansi  Y14.26  Meeting 

Cal  Poly  Modeling  Assignment 

IEEE/DASS  Steering  Committee  Meeting 

EDIF  PCB  Technical  Committee  Meeting 

Cal  Poly  Model  Review 

EIS  meeting  (J.  Ebel) 

ULCE  Architecture  Planning  Meeting 
TISSS  Informational  Meeting 
RAMCAD  TIM 
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Appendix  H 

DAYTON  REVIEW  OF  THE  CONCEPTUAL  SCHEMA, 

13  APRIL  1987 


CAL  POLY  TASK  TEAM 


Developing  a  view  In  both  directions: 
the  conceptual  data  o f  electrical  products 
IEEE  •  Academia  •  Industry 


California  Polytechnic  University 
Dept  of  Electrical  &  Computer  Engineering 
3801  W.  Temple  Avenue 
Pomona,  CA  91768-4065 
(714)  869-2511 


THE  DAYTON  REVIEW 
OF  THE 

IEEE/PDES  CONCEPTUAL  SCHEMA  FOR  ELECTRONIC  PRODUCT  DATA 


April  13-16,  1987 
Dayton,  Ohio 

-  REPORT  - 


Prepared  by  :  ML  Brei,  BITE  Inc. 

Prepared  for:  The  Institute  for  Defense  Analyses 


Attachments : 

(1)  Attendance  List 

(2)  Presentation  Material  Outline 

(3)  Model  Kit  4/11/87 

(4)  Test  Circuit  la 

(5)  Electrical  Functional  FEO  2.1.4 

(6)  IGES  Electrical  Functional  Conceptual  Schema 


The  final  review  of  the  IEEE/PDES  conceptual  schema  for  electronic 
product  data  (created  by  the  Cal  Poly  Task  Team)  was  held  on  April 
13-17,  1987  in  Dayton,  Ohio  under  the  auspices  of  the  Air  Force. 

Meeting  arrangements  were  handled  by  Universal  technology  Corporation. 

A  diverse  group  of  industry,  government,  and  defense  representatives 
attended  the  review.  The  broad  knowledge  base  of  the  participants 
contributed  to  lively  sessions  during  which  many  creative  and 
controversial  ideas  were  explored.  As  a  result,  a  greater  understanding 
of  the  strengths,  weaknesses,  and  potential  applications  of  the  model 
has  been  achieved. 

The  issues  raised  by  the  participants  and  other  highlights  of  the  review 
during  the  first  three  days  are  summarized  below.  (See  attachment  2  for 
the  presentation  material.) 


A.  CAL  POLY  TASK  TEAM  INTRODUCTION 


Roger  Gale,  D.  Appleton  Co.,  and  Curt  Parks,  General  Dynamics, 
discussed  the  background  of  the  Cal  Poly  Task  Team  and  the 
motivation  driving  the  modeling  effort.  A  tutorial  of  the  IDEFlx 
language  and  modeling  methodology  was  given  by  Roger  Gale.  The  IISS 
Information  Modeling  Manual  for  IDEFlx  was  distributed. 


B.  DETAILED  WALKTHROUGH 

A  detailed  examination  of  the  latest  version  of  the  Cal  Poly  model 
was  led  by.  Roger  Gale.  The  examination  consisted  of  an 
entity-by-entity  discussion  of  the  meaning  conveyed  by  the  model. 
The  model  kit  (attachment  4)  presents  the  model  incrementally. 
Several  of  the  entities  reflected  new  ideas  from  the  PDES  review 
held  in  Florida. 

The  walkthrough  revealed  both  strong  and  weak  aspects  of  the  model. 

The  entities  which  describe  connectivity  and  structure  are 
technically  sound. 

The  entities  which  describe  behavior  at  the  interface  of  a  device, 
however,  are  not  quite  right.  We  still  do  not  know  how  to  clearly 
define  the  level  of  detail  the  model  should  represent.  To  model 
the  behavioral  aspects  of  electronic  design  data,  we  must 
understand  how  to  describe  behavior  as  data.  The  general  consensus 
of  the  audience  was  that  the  input/output  and  signal  entities 
should  be  re-worked  completely. 


C.  TEST  CIRCUIT 

At  the  Cal  Poly  (March  23-26)  Review,  a  test  circuit  (attachment  4) 
was  devised  to  illustrate  how  to  build  instance  tables  for  the 
model.  Roger  Gale  presented  the  instance  tables  for  the  test 
circuit  and  explained  how  the  data  elements  in  the  tables  were 
derived.  Each  table  corresponds  to  an  entity  in  the  model.  The 
columns  represent  attributes.  The  rows  represent  specific 
occurences  of  each  entity. 


D.  THE  RELATIONSHIP  OF  THE  CAL  POLY  MODEL  TO  IGES 

John  Zimmerman,  Bendix  Corporation,  presented  an  excellent  analysis 
of  the  Cal  Poly  model  with  respect  to  an  IGES  electrical  subset 
schema  (attachment  6) .  The  analysis  consisted  of  the  creation  of 
an  IGES  electrical  schema,  comparing  the  IGES  schema  to  the  Cal 
Poly  schema,  and  comparing  the  IGES  schema  with  the  IGES  physical 
pointer  structure. 

The  IGES  schema  was  created  after  examining  the  IGES  Specification 
(Version  3.0)  Appendix  B,  "Electrical  Electronic  Product 
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Representation".  This  appendix  contains  descriptions  of  IGES 
concepts,  entities,  and  pointer  structures. 

The  connectivity  and  structure  entities  of  the  Cal  Poly  schema  have 
direct  counterparts  in  the  IGES  schema.  Thus,  the  mapping  from  the 
IGES  schema  to  the  Cal  Poly  schema  can  be  considered  one-to-one. 
This  discovery  has  very  important  implications  regarding  the  use  of 
the  Cal  Poly  model  to  analyze  the  semantic  content  of  various 
exchange  formats.  The  one-to-one  mapping  suggests  that  the 
conceptual  definition  of  connectivity  is  the  same  in  both  the  IGES 
and  the  Cal  Poly  schema. 

The  difference  between  the  two  schemas  is  their  respective  domains 
of  discourse. .  The  IGES  schema  represents  graphics.  The  Cal  Poly 
schema  intends  to  represent  abstract  functionality.  The  difference 
may  be  a  question  of  interpretation  or  perspective. 

The  critical  question  becomes,  "what  interpretation  will  stand  the 
test  of  time?".  One  interpretation  should  be  designated  the 
anchor  model  with  which  all  other  interpretations  are  associated. 
Until  we  can  determine  which  interpretation  persists  over  time 
(independent  of  technology) ,  mappings  among  diverse  interpretations 
may  be  ambiguous. 


E.  OUTSTANDING  ISSUES 

Many  issues  were  raised  throughout  the  model  review.  Unresolved 
questions  and  discussion  items  are  listed  here  for  future 
reference. 

1.  What  type  of  standard  intermediate  format/data  dictionary  is 
needed? 

We  need  a  good  mapping  language  which  is  both  machine 

understandable  and  human-digestable. 

Does  anyone  really  know  what  a  good  data  dictionary  is? 


2.  What  organization  will  assume  responsibility  for  the  configuration 
control  of  the  Cal  Poly  model? 

The  Cal  Poly  model  is  only  a  small  part  of  a  much  larger  model 
under  development  by  the  PDES  project  of  the  IGES  organization. 
The  IEEE  Design  Automation  Standards  Subcommittee  (DASS)  has  agreed 
to  support  the  model.  The  DASS  Electronic  Model  Working  Group 
(EMG)  will  contribute  to  the  on-going  development  of  the  model  and 
promote  the  use  of  the  model  to  understand  overlaps  among  different 
physical  formats.  The  configuration  control  of  the  model  will 
remain  in  the  context  of  the  PDES  effort. 

3.  Does  the  IDEFlx  language  and  methodology  have  the  expressive 
capability  required  for  modeling  complex  design  data? 
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-  Cardinality  is  limited  to  discrete  values  and  a  pre-defined  set 
of  ranges,  user-defined  ranges  can  not  be  expressed. 

-  Relationship  labels  are  non-unigue.  This  contradicts  standard 
data  modeling  practises  which  enforce  unique  relationship  labeling 
schemes. 

-  Conditional  relationships  can  be  expressed  via  the  generalization 
contruct.  The  IDEFlx  generalization,  however,  requires  exclusive 
categorization.  The  IDEFlx  methodology  does  not  encourage 
generalization  to  the  same  extent  as  other  data  modeling  practices. 

-  How  is  partial  and  potentially  inconsistent  design  data  modeled 
in  IDEFlx?  . 

-  Can  changes  and/or  alternates  be  modeled? 


4.  What  does  the  current  version  of  the  model  represent? 

The  ultimate  purpose  of  the  model  is  to  represent  abstract 
functionality.  A  description  of  abstract  functionality  includes 
static  and  dynamic  behavior,  connectivity,  and  the  parts  which  are 
interconnected.  Currently,  the  model  is  a  good  description  of 
connectivity  and  interconnected  parts.  The  behavioral  description, 
however,  requires  considerably  more  work. 

We  need  to  determine: 

-  What  is  meant  by  connectivity? 

-  What  is  meant  by  structure? 

-  What  is  meant  by  behavior? 


5.  How  are  we  going  to  get  the  vendors  involved? 


6.  What  should  be  done  next  with  the  Cad.  Poly  model? 

The  Cal  Poly  Task  Team  will  disband  after  preparing  a  final  report 
within  the  next  month. 

The  plans  of  the  IEEE/DASS  EMG  will  be  announced  at  the  culmination 
of  the  Cal  Poly  Task  Team  effort. 

A  brain-storming  session  on  Wednesday  afternoon  yielded  the 
following  ideas  as  follow-on  activities: 

Pursue  full  attribution  of  the  model  (non-key) 

-  Build  mappings  to  the  Cal  Poly  model  (the  model  will  serves  as  a 
unification  point)  from  IGES/EDIF/VHDL 
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-  Build  and  populate  a  simple  database 

-  Create  sample  outputs  (netlists,  parts  list...) 

-  Create  EDIF/IGES/VHDL  post-processors 

-  Develop  a  shareable  test  suite/benchmark  product  to  test 
versions  of  the  model,  the  database,  the  post-processors,  etc. 

-  Pursue  the  establishment  of  a  mapping  from  the  logical  solution 
data  (blue  stuff)  to  the  physical  solution  data  (red  stuff) . 

Form  an  ad  hoc  group  to  create  a  physical  model  by  Oct.  1987. 

-  Consider  how  spice,  hilo,  and  other  simulation  model  data  should 
be  incorporated  into  the  model. 

Do  some  additional  work  with  the  signal  concept. 


Attachment  1 


ATTENDANCE  LIST 
FOR 

POES  electrical  committee  meeting 

13-17  April  1987 
Stouffer's  Dayton  Plaza  hotel 
Dayton,  Ohio 
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Lougie  Anderson 
Principal  Scientist 
Tektronix 

P.O.  Box  500,  MS  50-662 
Beauton,  OR  97077 
(503)  627-2145 

ML  Hooper  Brei 
Software  Engineer 
Bite,  Incorporated 
9254  Center  Street 
Manassas,  V A  22110 
(703)  361-7050 

Roger  Gale 
Sr.  Consultant 
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Attachment  2 

IEEE 

A  CONCEPTUAL  SCHEMA  FOR  SHARED  PRODUCT  DATA 

PRESENTATION  MATERIAL 


cpl-01  WORKSHOP  AGENDA 

Oay  1  :  Introduction:  Purpose,  Players,  Plans,  and  Goals 
Tutorial:  Reading  IDEF1-X 
Model  Walk-through:  Part  1 

Day  2  :  Model  Walk-through:  Part  2 

Day  3+:  Workshops 

cpl-02  SCHEDULED  REVEIWS  AND  WORKSHOPS 


10-13  March  87 

23-27  March  87 

13-17  April  87 


EAST  COAST 

Computervision:  Bedford,  MA 
Mr.  Alex  Rawling  617-275-1800 
Dr.  Charles  Savage  617-431-7207 
WEST  COAST 

California  Polytechnic  Univ.;  Pomona 
Prof.  Richard  Cockrum  714-869-2511 
Curtis  H.  Parks  713-868-4923 
DELIVERABLES  Review 
Stouffer‘s  Inn;  Dayton,  Ohio 
PDES  Registration  Desk  513-426-8530 


cpl-03  WORKSHOP  TEAM  LEADERS 

0  ROGER  GALE:  D.  Appleton  Comoany,  Inc. 
#  CURTIS  PARKS:  General  Dynamics/Pomona 


cpl-04  INTRODUCTIONS 

0  Name  and  Organization 

#  General  Background,  Experience 

•  Purpose  for  attending  and  Expectations 

cpl-05  THE  CAL  POLY  TASK  TEAM 

*  Hosted  by  the  ECE  Department:  Prof.  R.  Cockrum. 

0  Full-time,  6-week  effort  to  develop  an  initial 

public  domain  Electronic  Product  Data  Model 
(January  12  to  February  28). 

•  Participating  Organizations:  DACOM,  McDonnell  Douglas 
Astronautics,  Douglas  Aircraft  Company,  STC  Technology, 
General  Dynamics/Pomona,  Westinghouse  Electric  Corp., 

BITE  Inc.,  The  Institute  for  Defense  Analysis,  Viewlogic 
Systems  Inc.,  Digital  Equipment  Corp.,  and  Hughes/Fullerton. 

cpl-06  CAL  POLY  TASK  TEAM  CONTRIBUTORS 


M.  L.  Brel  -  Bite  Inc. 

Richard  Brooks  -  McDonnell  Douglas  Astronautics 
Dr. David  Chalmers  -  STC 
Roger  Gale  -  D.  Appleton  Co. 

George  Goldsmith  -  McConnell  Douglas  Astronautics 
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CAL  POLY  TASK  TEAM  CONTRIBUTORS  -  cont'd. 


Kaz  Hori  -  McDonnell  Douglas  Astronautics 

Jerry  Kane  -  Westinghouse 

Andrew  Moulton  -  Viewlogic  Systems 

Paul  Nelson  -  Hughes  Aircraft  Co.  Ground  Support  Group 

Curtis  Parks  -  General  Dynamics  Pomona  Division 

Tom  Smith  -  Digital  Equipment  Corp. 

Via  Telephone: 


Bert  Gibbons  -  Westinghouse 

Erich  Marschner  -  CAD  Language  Systems 

John  Zimmerman  -  Bendix  Kansas  City  Division 

cpl-07  BACKGROUND 

0  Product  Data  Exchange  Specification  (PDES)  effort 
0  IEEE  Design  Automation  Standards  Subcommittee  (DASS) 

0  Cal  Poly  Task  Team  full-time  working  sessions 

cpl-08  CAL  POLY  TASK  TEAM  GOAL 

Create  an  electronic  product  data  model  depicting  fundamental 
data  elements,  attributes,  and  relationships.  The  mooel  will 
be: 

“  CONCEPTUAL, 

°  neutral , 

°  in  the  public  domain,  and 

°  the  result  of  a  cooperative  effort  among  diverse 
piayers  of  trie  electronics  industry. 

This  data  model  will  be  the  initial  IEEE  Conceptual  Schema 
for  Shared  Product  Data. 

cpl-09  CAL  POLY  TASK  TEAM  OBJECTIVES 

0  Use  the  IDEF1-X  language  and  methodology  tc  create  the 
model . 

°  Establish  an  expert  participant  base  from  diverse 
segments  or  the  electronics  industry  and  acaoemia. 

°  Prepare  supporting  material  to  be  submitted  to  the 
appropriate  publications  for  widespread  dissemination 
to  the  public. 

cpl-10  CAL  POLY  TATK  1 EAM  ACCOMPLISHMENTS 

8  A.  Proposed  Conceptual  Data  Mooel. 

8  Participation  from  a  diverse  segment  of  the  Industry. 

8  Supporting  documentation  and  source  material  to  be 
used  by  future  modeling  efforts. 

8  (■  realistic  understanding  of  the  magnituoe  of  the 

mooe i ing  task. 
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cpl-11  WHAT'S  NEXT? 

0  Continue  to  validate  the  Conceptual  schema  by 
testing  it  in  real-world  situations. 

0  Continue  to  refine  and  enhance  the  schema  through 
participation  in  the  cognizant  IEEE  DASS  working 
groups. 

0  Integrate  the  schema  with  related  efforts  currently 
underway  in  projects  such  as  PDES,  EIS,  CALS,  etc. 
cpl-11. 1  0  Continue  to  refine  and  enhance  the  schema  through  participation 
in  the  cognizant  IEEE  DASS  working  groups. 

°  The  model  needs  to  be  populated  with  non-key  attributes. 

°  Defined  Electrical  Properties 
°  Network  Constraints 

0  The  Physical  Definition  data  of  electrical  and  electronic 
oarts  needs  to  be  modeled. 

0  The  Intersection,  or  mapping,  between  the  functional  model 
and  the  physical  definition  neeas  to  be  modeled. 

0  “Change"  data  needs  to  be  modeled. 

Cpl-12  CAL  POLY  TASK  TEAM  MOTIVATION 


°  THE  DATA  PROBLEM:  a  monster 
0  INTERORGANIZATION  SHARING 
0  INTRAORGANIZATION  SHARING 
0  CONCERNED  GROUPS:  seeking  solutions 
(i.e.  the  IEEE.  PDES,  CALS,  etc.) 

°  THE  3-SCHEMA  CONCEPT:  a  viable  approach 

cpl-13  THE  DATA  PROBLEM 


0  Islands  of  Automation 
0  The  Need  to  Share 
°  Interfacing  is  an  expensive  solution 
0  Running  a  phone  wire  does  not  ensure  communication 

cpl-14  A  SOLUTION  STRATEGY  FOR  THE  PROBLEM 

°  MANAGE  Da i A  FROM  A  DATA  PERSPECTIVE 
°  STANDARDIZE  THE  MEANINGS  OF  DATA 

0  INDEPENDENT  FROM  ITS  USES  (APPLICATIONS) 

°  INDEPENDENT  FROM  ITS  STORAGE  TECHNOLOGY 
(DATABASES,  FILES,  TRANSFER  FORMATS) 
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cpl-17  PURPOSE 

0  To  specify  INFORMATION  REQUIREMENTS  from  an 
enterprise  view 

0  To  provide  a  control  point  for  integration  architectures 

*  To  build  shareable  databases 

0  To  analyze  the  expressiveness  of  transfer  formats  and 
design  languages. 

cpl-18  THE  LANGUAGE  OF  THE  MODEL 

*  Developed  as  part  of  the  USAFICAM  Project 
°  Named  IDEF1-X 

cp 1 -21  CAL  POLY  TASK  TEAM  SCOPE  PRIORITIES 

*  Cannot  capture  the  coneptual  data  of  the  entire  electronic 
product  data  universe  in  6  weeks. 

0  Narrowed  the  scope  to  the  data  of  the  design  solution 
ready  for  manufacturing. 

°  Initial  focus  on  FUNCTIONAL  DESIGN. 

0  Wait  to  see  if  the  PDES  Mechanical  Products  model  will 
satisfy  our  needs. 

cp 1-22  TASK  TEAM  SCOPE  ISSUES 

0  DIFFERENTIATION  OF  KINDS  OF  DATA 
0  REQUIREMENTS 

*  DESIGN  SOLUTIONS 

0  STARTED  WITH  TWO  KINDS 
0  FUNCTIONAL 

*  PHYSICAL 

0  A  "DESIGN  VIEW"  MODEL  WAS  THE  TRIGGER  TO  A  NEW 
UNDERSTANDING 

cpl-27  TASK  TEAM  SCOPE  ISSUES 

0  USE  THE  "DESIGN  ELECTRICAL  AND  ELECTRONIC  PRODUCTS 
ACTIVITY  MODEL 

0  THE  "GREEN  STUFF"  IS  IN  THE  CONTROL  OF  ACTIVITY  A1 
cpl-28  THE  MODEL  WALKTHROUGH 

Rules  Of  Procedure: 

1.  Team  leaders  will  present  the  model  during  the  review. 

2.  Questions  are  encouraged  during  the  review. 

3.  Issues  should  be  identified  throughout  the  review. 

4.  Issues  will  not  be  resolved  during  the  review. 

5.  The  workshops  will  be  problem-solving  sessions. 
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A  CONCEPTUAL  SCHEMA  FOR  SHARED  PRODUCT  DATA 


cpl-29  THE  FUNCTIONAL  MODEL 


0  Diagrams 
°  Glossary  of  Terms 
Entity  Definitions 
Attribute  Definitions 
0  Business  Rules 

cpl-29  (.all)  Refer  to  Model  KIT 

cpl-30  THE  PHYSICAL  DATA  MODEL 

•  The  PDES  Mechanical  Products  Mode!  will  oe  examined 
to  see  that  it  satisfies  the  needs  for  electronic  and 
electrical  products. 

°  FEO  3.1.1  illustrates  the  mapping  between  the  functional 
and  physical  data  via  the  ELECTRICAL  TERMINAL  construct. 

cpl-31  (Note:  FEO  3.1.1  is  FEO- 11  in  Model  KIT 

cpl-32  PROBLEMS,  problems! 

cpl-33  OPEN  ISSUES  FROM  BOSTON  WALKTHROUGH 


0  Feedback  -  Cases  wnere  the  output  depends  not  only  on 
present  states,  but  some  prior  state,  condition,  signal 
or  time. 

0  Delay/Time  Based  Phenomena  -  Relationships  among  signals 
or  signal  states  which  vary  by  defined  frequency,  time, 
phase,  etc. 

0  Relationships  among  ordered  sets  of  signals  or  states. 

0  Non-voltage  signals  (many  electrical  functional  units 
have  outputs  which  are  radiation  or  mechanical  motion). 

°  Data  representation  of  analog  etc.  signals. 
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CAL.  POLY  TASK  TEAM 
ELECTRONIC  AND  ELECTRICAL  DATA  MODEL 

GLOSSARY 


ENTITY  DEFINITIONS 

Constituent  Physically  Defined  Product  Item 

Data  that  establishes  that  one  Physically  Defined  Product  Item  is  a  necessary  constituent  ot  another. 

Defined  Electrical  Logical  Intranllnk  Constraint 

Data  which  sets  limiting  values  for  a  functional  charactenstic,  contained  within  a  single  network,  which 
must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical  connections  are 
implemented.  An  example  might  be  a  length  constraint  in  terms  of  wavelengths  at  a  specified 
operating  frequency. 

Defined  Electrical  Logical  Link 

Data  about  the  logical  electrical  connectivity  within  a  Functional  Unit.  It  establishes  a  set  of  two  or  more 
Electrical  Nodes  or  one  Defined  Functional  Port  and  one  or  more  Electrical  Nodes  as  being  electrically 
in  common. 

Defined  Electrical  Logical  Link  Group 

Data  that  establishes  that  one  or  more  Defined  Electrical  Logical  Links  are  combined  into  a  group  tor 
some  purpose. 

Defined  Electrical  Logical  Link  Group  Member 

Data  that  a  Defined  Electrical  Logical  Link  is  a  member  of  a  Defined  Electrical  Logical  Link  Group. 

Defined  Electrical  Logical  Link  Intergroup  Constraint 

Data  which  sets  limiting  values  tor  a  functional  characteristic  among  Defined  Electrical  Logical  Link 
Groups  which  must  be  satisfied  by  the  physical  design  in  which  the  corresponding  physical 
connections  are  implemented.  Examples  would  be  capacitance  limits  or  an  insulation  resistance 
requirement. 

Defined  Electrical  Property 

Data  about  electrical  characteristics  of  a  Defined  Funtional  Unit  existing  between  two  Defined 
Functional  Ports.  For  example,  resistance,  capacitance  or  inductance  which  are  usually  thought  of  as 
’static’  rather  than  ‘dynamic*.  (These  properties  do  have  some  variation  such  as  the  temperature 
coefficient  of  resistance  for  a  resistor). 

[Entities  and  attributes  to  capture  the  data  of  these  variations  have  not  yet  been  modeled.] 
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GLOSSARY 

PNTITY  DEFINITIONS 
Defined  Electrical  Signal 

Data  used  to  define  the  behavior  of  a  Defined  Functional  Unit,  expressed  in  terms  of  electrical 
potential  difference  between  two  Defined  Functional  Ports.  ( It  is  through  the  data  which  defines  the 
relationships  of  output  signals  to  input  signal  states  that  dynamic  behavior  of  'active'  Defined 
Functional  Units  is  captured.  The  characteristic  curves  of  a  transistor  can  be  derived  by  common, 
curve  fitting  algorithms  from  sets  of  these  data.) 

Defined  Functional  Port 

Data  describing  the  logical  accessibility  to  one  of  the  functions  of  a  Defined  Functional  Unit.  fThese 
pons  are  what  is  represented  by  lines  or  other  graphic  symbols  identifying  inputs  and  outputs  tor 
electrical  devices.  The  Pori  is  a  characteristic  of  a  Functional  Unit  definition  without  its  having  a  usage. 
The  port  can  be  thought  of  as  a  window  through  which  the  boundary  networks  ot  the  functional  unit 
are  seen.  When  a  Defined  Functional  Unit  is  given  an  instance  of  use  (Defined  Functional  Sub  Unit 
Occurrence),  then  the  port  becomes  an  Electrical  Node  of  its  higher  assembly.) 

Defined  Functional  Sub  Unit  Occurrence 

Data  that  a  particular  Defined  Functional  Unit  occurs  as  a  component  of  another  Defined  Functional 
Unit.  There  is  an  instance  of  this  entity  for  each  occurrence  of  a  Defined  Functional  Unit  within  the 
same  higher  level  Defined  Functional  Unit.  This  provides  a  functional  view  of  the  vanous  levels  of 
component/assembty  product  relationship. 

Defined  Functional  Unit 

Data  about  the  functional,  or  performance,  aspects  of  a  portion  of  a  system.  A  Defined  Functional 
Unit  may  be  a  sub  unit  of  another  Defined  Functional  Unit  and  it  may  have  sub  units  of  its  own. 

Defined  Functional  Unit  Input  State  (a  set  of  stimuli) 

Data  about  conditions  tor  a  specific  Functional  Unit.  (Through  the  Defined  input  State  Signal 
associative  entity,  a  particular  input  state  is  defined  as  consisting  of  one  or  more  Defined  Electrical 
Signals,  in  the  electrical  application.) 

Defined  Functional  Unit  Output  Signal  Related  Input  State 

Data  that  establishes  that  a  Defined  Functional  Unit  Output  Signal  results  from  a  Defined  Functional 
Unit  Input  State. 

Defined  Functional  Unit  Output  Signal 

An  output  signal  of  a  particular  Defined  Functional  Uni 
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GLOSSARY 


Defined  Functional  Unit  Output  Signal  Propagation  Delay  Specification  (response 
time) 

Data  that  a  Functional  Unit  Output  Signal  is  required  to  be  present  within  a  specified  time  alter  trie 
related  Specified  Functional  Unit  Input  State  has  been  established. 

Defined  Input  State  Signal 

Data  that  establishes  a  particular  Defined  Electrical  Signal  as  being  a  pan  of  a  Defined  Functional  Unit 
input  State. 

Electrical  Logical  Link  Node 

Data  that  an  Electrical  Node  is  pan  of  a  Defined  Electrical  Logical  Link. 

Electrical  Logical  Link  Port 

Data  that  a  Defined  Functional  Port  is  part  of  a  Defined  Electrical  Logical  Link.  Each  Defined 
Functional  Port  can  be  a  member  of  only  one  Defined  Electrical  Logical  Link. 

Electrical  Node 

Data  about  a  logical  (functional)  aceessability  to  the  functionality  of  a  specific  occurrence  of  a 
Functional  Unit.  This  entity  serves  to  collect  the  Defined  Functional  Port  ID  (e.g..  Pin  Number) 
together  with  the  reference  label  of  the  occurrence  of  the  Defined  Functional  Sub  Unit  Occurrence 
(e.g.,  U2-Pin  1). 

Electrical  Terminal 

The  three-dimensional  object  at  a  physical  place  for  connection  to  the  functionality  of  a  Product  item. 
Examples  are  the  leads  on  an  axial  lead  resistor,  the  leads  on  a  TO-18  transistor  and  the  pins  of  an 
electrical  connector. 

Electrical  Terminal  Electrical  Logical  Link  Node  Site 

Data  that  a  particular  occurrence  of  an  Electrical  T ermmal  is  a  physical  instance  of  a  particular  Eieancal 
Logical  Link  Node.  (This  is  the  mapping  between  a  specific  physical  terminal  definition  and  the 
functional  node.) 

Electrical  Terminal  Occurrence  Location 

Data  that  establishes  a  defined  location  tor  an  instance  of  an  Electncal  Terminal  within  a  higher 
assembly. 
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GLOSSARY 

PNTITY  DEFINITIONS 
Physically  Defined  Product  item 

An  aggregation  all  of  the  defined  characteristics  of  a  Product  Item.  The  physical  shape  and  size  are 
collected  here  and  the  mappings  of  functional  charactenstics  from  the  functional  definition  are  also 
collected  by  this  entity.  This  is  the  entity  which  has  a  “part  number'  as  its  key. 

Physically  Defined  Product  Item  Occurrence 

For  each  occurrence  of  the  Constituent  Physically  Defined  Product  Item  there  is  an  instance  of  this 
entity.  Each  instance  within  the  same  higher  item  acquires  a  unique  identity  and  location  within  the 
attributes  of  this  entity. 

Physical  Port 


Data  that  collects  shape  and  size  elements  (geometry,  topology  and  tolerances)  and  permits  mapping 
them  as  an  Electncal  Terminal.  It  may  be  noted  that  this  model  allows  one  shape  and  size  definition  to 
be  used  to  define  more  than  one  Electncal  Terminal.  (This  seems  to  be  an  example  of  the  PDES 
mechanical  products  model  idea  of  Shape/Size  Element  Group.) 
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CAL.  POLY  TASK  TEAM 
ELECTRONIC  AND  ELECTRICAL  DATA  MODEL 

GLOSSARY 

ATTRIBUTE  DEFINITIONS 
Daflned  Electrical  Property  Name 

Trie  name  of  a  specific  Electrical  Property  existing  between  two  Ports  of  a  Defined  Functional  Unit. 
These  are  such  names  as  Resistance,  Capacitance,  inductance,  etc.. 

Daflned  Electrical  Property  Units 

Identification  of  trie  kind  of  units  in  which  an  Electrical  Property  Value  is  expressed.  Examples  are 
Ohms.  Farads,  etc.. 

Defined  Electrical  Propeny  Value 

The  value,  or  quantity,  of  an  Electrical  Property 
Delay  Specification 

An  expression  of  a  constraint  of  the  delay  from  the  establishment  of  the  related  Defined  Functional 
Unit  Input  State  before  the  Defined  Functional  Unit  Output  Signal  must  be  present.  Most  likely 
expressed  in  time  units. 

[Further  examination  of  this  attribute  will  probably  result  in  additional  attributes  and.  perhaps,  entities.! 
Electrical  Logical  Link  ID 

An  identification  of  an  Electrical  Logical  Link  which  is  unique  within  a  particular  Defined  Functional 
Unit.  May  be  numeric  or  alphabetic. 

Electrical  Logical  Link  Group  ID 

An  identification  of  an  Electrical  Logical  Link  Group  which  is  unique  within  a  particular  Defined 
Functional  Unit.  May  be  numeric  or  alphabetic. 

Functional  Unit  ID 

A  unique  identifier  assigned  by  the  enterprise  to  each  Defined  Functional  Unit.  Most  commonly  this  is 
a  meaningful  name.  An  example  might  be  'multiplexer  assembly*. 

[When  trie  present  model  is  integrated  into  a  larger  enterprise  or  PDES  conceptual  data  model  it  is 
probable  that  a  completely  unique  identification  will  require  a  concatenation  of  several  attributes. 
These  are  likely  to  include  the  identification  of  the  enterprise  which  establishes  (or  owns)  this 
definition  and  a  product  or  model  identification  as  well  as  a  functional  unit  name.] 
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GLOSSARY 

ATTRIBUTE  DEFINITIONS 
input  State  ID 

An  identifier  assigned  by  the  enterprise  to  each  input  signal  state  within  the  definition  of  a  Defined 
Functional  Unit.  Thus,  the  identifier  is  unique  only  within  the  context  ot  a  specific  Defined  Functional 
Unit  and  the  combination  of  Functional  Unit  ID  and  Input  State  ID  is  unique  within  the  enterprise. 

Port  ID 

An  identifier  assigned  to  each  Defined  Functional  Port  of  a  Defined  Functional  Unit. 

Signal  ID 

An  identifier  assigned  to  uniquely  distinguish  a  signal,  which  appears  between  the  same  pair  of  ports, 
from  another. 

( If  the  functional  unit  that  is  being  defined  is  a  digital  unit,  then  typical  signals  are  trains  of  digital 
pulses.  These  can  be  most  simply  defined  as  two  signals,  a  high  and  a  low.  Where  the  functional  unit 
is  something  such  as  a  transistor,  there  could  be  many  signals  defined,  each  having  a  different 
voltage  value.) 

Signal  Units 

Identification  of  the  kind  of  units  in  which  the  value  of  the  signal  is  expressed. 

Signal  Value 

A  number  indicating  the  quantity  of  the  units  ot  the  particular  signal. 

Sub  Unit  Occurrence  Identification 

An  identification  assigned  to  a  particular  occurrence  of  a  Defined  Functional  Unit  within  another 
Defined  Functional  Unit.  (The  most  common  form  of  this  in  electrical  design  is  a  reference 
designation.  The  same  functional  resistor  used  twice  in  a  higher  unit  might  be  designated  Ri  in  one 
occurrence  and  R2  in  the  other.) 
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BUSINESS  RULES  OF  THE  E/E  CONCEPTUAL  MODEL 


This  section  presents  the  business  rules  of  the  E/E  conceptual  model  in  English.  The  rules  are 

grouped  by  entities.  Entity  names  are  distinguished  by  bold  Italics.  The  number  scheme  below  does 

not  correspond  to  number  schemes  used  in  other  documentation. 

1.  A  Defined  Functional  Unit  has  0, 1 ,  or  many  Defined  Functional  Unit  Input  States. 

2.  A  Defined  Functional  Unit  contains  0, 1.  or  many  Defined  Functional  Ports. 

3.  A  Defined  Functional  Unit  is  0,1,  or  many  Defined  Functional  Sub  Unit  Occurrences. 

4.  A  Defined  Functional  Unit  has  0,  1,  or  many  Defined  Functional  Sub  Unit 
Occurrences. 

5.  A  Defined  Functional  Unit  contains  0, 1 ,  or  many  Defined  Electrical  Logical  Links. 

6.  A  Defined  Functional  Unit  contains  0,  1,  or  many  Defined  Electrical  Logical  Link 
Groups. 

7.  A  Defined  Functional  Unit  Input  State  is  0,  1,  or  many  Defined  Functional  Unit 
Output  Signal  Related  input  States. 

8.  A  Defined  Functional  Unit  Input  State  is  composed  ofl  or  many  Defined  Input  State 
Signals. 

9.  A  Defined  Functional  Port  is  a  reference  port  for  0.  1,  or  many  Defined  Electrical 
Properties ). 

10.  A  Defined  Functional  Port  is  a  measurement  port  for  0, 1 ,  or  many  Defined  Electrical 
Properties ). 

11.  A  Defined  Functional  Port  is  a  reference  port  for  0. 1,  or  many  Defined  Electrical  Signals. 

1 2.  A  Defined  Functional  Port  is  a  measurement  pon  tor  0, 1 ,  or  many  Defined  Electrical 

Signals. 

13.  A  Defined  Functional  Port  isOorl  Electrical  Logical  Link  Ports. 

14.  A  Defined  Functional  Port  becomes  0,  i ,  or  many  Electrical  Nodes. 

15.  A  Defined  Functional  Sub  Unit  Occurrence  contains  0, 1 ,  or  many  Electrical  Nodes. 

16.  A  Defined  Electrical  Logical  Link  includes  0  or  i  Electrical  Logical  Link  Ports. 

17.  A  Defined  Electrical  Logical  Link  is  composed  of  1  or  many  Electrical  Logical  Link 
Nodes. 

18.  A  Defined  Electrical  Logical  Link  has  0,  1,  or  many  Defined  Electrical  Logical 
IntraLInk  Constraints. 

19.  A  Defined  Electrical  Logical  Link  is  0,  1  or  many  Defined  Electrical  Logical  Group 
Members. 

20.  A  Defined  Electrical  Logical  Link  Group  is  the  1st  logical  link  group  of  0,  1,  or  many 
Electrical  Logical  Link  Defined  Constraints. 

21.  A  Defined  Electrical  Logical  Link  Group  is  the  2nd  logical  link  group  of  0.  1,  or  many 
Electrical  Logical  Link  Defined  Constraints. 
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22.  A  Defined  Electrical  Signal  is  0,1,  or  many  Daflnad  Functional  Unit  Output  Signals. 

23.  A  Daflnad  Electrical  Signal  is  0,1,  or  many  Daflnad  Input  Stata  Signals. 

24.  A  Daflnad  Functional  Unit  Output  Signal  has  0  or  1  Daflnad  Functional  Unit  Output 
Signal  Propagation  Dalay  Definitions. 

25.  A  Daflnad  Functional  Unit  Output  Signal  results  from  at  least  i  Daflnad  Functional 
Unit  Output  Signal  Ralatad  Input  Stata. 

26.  An  Electrical  Node  is  0, 1 ,  or  many  Electrical  Logical  Link  Nodes. 
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APPENDIX  3 

EL ECTR.ICAL/EL ECTRONIC  PRODUCT  REPRESENTATION 
INTRODUCTION 
Purpose 

The  purpose  of  this  Appendix  is  to  provide  ICES  implementors  And  users  with  a 
roadmap  of  the  ICES  representation  of  electrical/ electronic  product  designs. 
The  topics  of  discussion  will  include  (but  are  not  limited  to)  design, 
'engineering,  manufacturing,  testing,  and  inspection. 

Assumptions 

The  reader  should  have  a  basic  understanding  of  electrical/ electronic  product 
design  using  CAD/CAM/CAE  tools,  including  (but  not  limited  to)  connectivity, 
component  descriptions,  placement  and  routing,  and  the  manufacturing 
interface.  Each  topic  will  be  discussed  in  general,  but  these  discussions  are 
not  intended  to  provide  a  tutorial  in  the  subject. 

CONNECTIVITY 

In  General 

Forming  a  connection  between  two  or  more  items  requires  the  ability  to 
represent  the  following: 

(1)  the  exact  location  of  each  connection  point 

(2)  the  signal  formed  and  its  identification  (If  any) 

(3)  the  physical  connection  between  the  items  Of  any) 

The  term  "connect  node"  will  refer  to  a  database  entity  which  represents  the 
exact  location  of  connection.  The  term  "link"  will  refer  to  the  representation 
of  the  signal  formed,  and  "signal  name"  will  refer  to  the  signal  identifier.  The 
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term  "join"  will  reler  to  the  database  entity  or  entities  which  represent  the 
physical  connection  between  the  items. 

Each  item  to  be  connected  requires  a  connect  node  to  represent  each  possible 
connection  point  of  the  item.  A  signal  may  be  formed  between  any  such  items 
by  a  link  which  references  the  connect  nodes  to  be  connected.  Thu  creates  an 
associativity  between  the  connect  nodes,  and  thus  the  connected  items.  The 
signal  name  may  be  used  to  uniquely  identify  the  particular  signal  formed. 
The  join  may  be  used  to  provide  a  graphical  representation  of  the  signaL  In 
electrical  applications  the  join  will  most  often  be  represented  by  a  line 
(schematic)  or  a  widened  line  (printed  wiring  board). 

In  electrical  applications,  the  items  to  be  connected  are  typically  electrical 
components  (i.e.,  resistor,  16-pin  DIP,  etc.).  Most  often,  these  components  are 
represented  by  subfigures  which  are  defined  once,  then  referenced  (instanced) 
in  the  database  lor  each  occurrence  of  the  component.  Each  pin  of  the 
component  is  a  potential  connection  point  in  a  signal;  thus  each  subfigure  has  a 
connect  node  defined  for  each  pin.  When  such  a  subfigure  is  instanced,  its 
connect  nodes  must  also  be  instanced.  This  allows  each  connect  node  to 
participate  in  the  unique  signal  to  which  it  belongs.  An  instanced  connect 
node,  when  added  to  a  signal,  is  different  from  its  definition  which  is  not  a 
member  of  any  signal. 

These  subfigures,  representing  electrical  components,  often  contain  text 
describing  the  component  and  its  pins.  In  some  cases  (e.g.,  part  number),  this 
text  is  fixed  and  unchanging.  In  other  cases  (e.g.,  reference  designator),  the 
text  may  be  variable,  and  thus  may  not  be  filled  in  until  the  subfigure  is 
instanced.  This  text  (sometimes  called  a  "text  node"),  like  the  connect  node, 
is  instanced  along  with  its  parent  subfigure,  in  some  cases,  a  connect  node  and 
a  text  node  are  related  (e.g.,  the  connect  node  represents  a  component  pin  and 
the  text  node  represents  the  pin  number). 
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In  IC15 

In  ICES,  tne  connect  node  is  represented  by  the  Connect  Point  entity.  The 
text  node  is  represented  by  the  Text  Display  Template  entity.  The  Flow 
Associativity  entity  represents  a  signal  and  contains  the  link,  signal  name,  and 
pointers  to  the  join  entities.  The  Network  Subfigure  entities  (definition  and 
instance)  represent  electrical  components  which  participate  in  signals.  A 
number  of  property  entities  will  also  be  used,  as  mentioned  below. 

Network  Subfigure  Construction 

A  component  is  constructed  using  the  Network  Subfigure  Definition  entity. 

■  The  graphics  representing  the  component  geometry  are  referenced  as  for  the 

Subfigure  Definition  entity.  In  addition,  a  separate  set  of  pointers  to  defining 
Connect  Point  entities  is  provided.  These  Connect  Point  entities  define  the 
locations  and  characteristics  of  the  component's  pins.  Properties,  for  example 
the  Part  Name  property,  may  be  attached  to  the  Network  Subfigure  Definition 
entity. 

Connect  Points 

A  component  pin  (or  surface  mounted  device  pad,  IC  I/O  port,  lead  frame, 
schematic  symbol  lead,  etc.)  is  represented  by  the  Connect  Point  entity.  The 
Connect  Point  entity  is  used  in  both  logical  and  physical  product  designs.  The 
exact  location  in  model  space  is  spetified,  along  with  several  characteristic 
flap  (connection  type,  function  type,  I/O  direction).  There  is  a  pointer  to  the 
|  parent  Network  Subfigure  entity  (definition  or  instance),  which  provides  a 

■  much-needed  association  for  signal  processing.  An  additional  Subfigure 

B  Instance  pointer  is  provided  for  Connect  Point  display.  This  allows  a  graphical 

I  symbol  to  be  displayed,  representing  the  Connect  Point,  The  pin  number  is 

■  provided  in  the  Function  Connect  Point  Identifier  field,  along  with  a  pointer  to 

r  a  Text  Display  Template  for  pin  number  display.  A  pin  function  name  is 

I  provided  in  the  Connect  Point  Function  Name  field,  along  with  a  pointer  to  a 

B  Text  Display  Template  for  its  display. 
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Signal  Construction 

A  signal,  representing  one  set  of  elecrically  common  Connect  Points,  is 
constructed  using  the  Flow  Associativity  entity.  It  contains  pointers  to  otner 
associated  Flow  Associativity  entities,  the  Connect  Point  entities 
participating  in  the  signal  (this  is  the  Link),  and  the  loin  entities  representing 
the  geometry  of  the  signal  (either  logical  or  physical).  Also  contained  is  a  list 
of  signal  names  wrucn  may  be  used  to  identify  the  signal,  along  with  a  set  of 
pointers  to  Text  Display  Template  entities  which  may  be  used  to  display  the 
first  signal  name  in  a  number  of  locations.  Two  characteristic  flags  determine 
the  signal  type  (logical  or  physical),  and  the  function  type  (fluid  flow  or 
electrical  signal). 

A  signal,  then,  is  represented  by  one  Flow  Associativity  entity  pointing  to  a 
set  of  electrically  common  Connect  Points.  This  is  the  Link.  The  loin  entities 
represent  the  physical  display  geometry  at  the  signal.  For  a  schematic 
(logical),  a  line  without  width  is  typically  used.  For  a  primed  board  (physical), 
a  line  with  the  Line  Widening  prooerty  is  typically  used.  A  number  of  signal 
names  may  be  associated  with  the  signal.  Multiple  displays  of  the  first,  or 
primary,  name  are  possible. 

The  components  participating  in  a  signal  are  represented  by  the  Network 
Subfigure  Instance  entity.  Note  that  the  Connect  Poim  entities  "belonging"  to 
a  component  are  instanced  along  with  the  subfigure.  This  is  necessary  to  allow 
a  subfigure  to  participate  in  a  number  of  different  signals,  while  retaining 
ixiique  component/pin  identification.  Each  component  is  usually  identified  by 
a  reference  designator.  This  is  supplied  by  the  Primary  Reference  Designator 
field  of  the  Network  Subfigure.  Any  alternate  reference  designators  may  be 
designated  with  the  Reference  Designator  property,  attached  through  the 
normal  property  pointer  mechanism. 

Information  Display 

Throughout  the  above  discission,  references  to  the  Text  Display  Template 
entity  have  been  made.  This  entity  allows  text,  embedded  in  an  entity,  to  be 
displayed  without  the  redundant  specification  of  the  text  string.  There  are 
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two  reasons  for  this  feature.  First,  it  eliminates  a  possible  source  of  error  by 
allowing  the  information  to  be  specified  in  only  one  place.  Second,  it  reauces 
the  file  sice  overhead.  This  entity  exists  in  two  forms,  absolute  and 
incremental.  The  absolute  form  provides  an  exact  location  for  display  of  the 
information,  as  in  the  display  of  a  reference  designator.  The  incementai  form 
provides  an  offset  to  be  applied  to  the  parent  entity1;  location  to  provide  the 
exact  location  for  display  of  information  like  pin  numbers.  Vhen  a  direct 
pointer  for  information  display  is  provided,  the  base  location  is  readily 
determined  from  the  parent  entity's  location  such  as  when  displaying  a  pin 
number.  In  the  case  of  property  value  display,  the  base  location  must  be 
determined  by  "remembering"  the  location  of  the  property  entity's  parent 
entity.  This  wouio  occur  when  displaying  the  Psrt  Name.  Also  in  this  case, 
the  pointer  to  the  Text  Display  Template  entity  is  located  in  the  additional 
pointers  section  of  the  property  entity  parameters. 

Additional  Considerations 

The  situation  is  exactly  the  same  for  both  logical  and  physical  representations. 
The  only  Aflerences  arise  in  the  subfigure  and  3oin  entities  used.  In  fact,  a 
file  may  contain  representations  for  both  the  schematic  and  the  board.  The 
Flow  Associativity  entity  contains  a  type  flag  to  indicate  the  connection  type 
(logical  or  physical).  In  this  case,  one  Flow  Associativity  would  represent  the 
logical  connection  and  a  second  the  physical  connection.  The  two 
associativities  would  b*  related  by  the  pointers  provided  in  tne  Flow 
Associativity. 

Figures 

The  following  figures  illustrate  certain  aspects  of  the  above  discussions. 
Figure  S-l  illustrates  the  basic  entity  relationships.  Figure  5-2  and  Table  B-l 
illustrate  the  usage  of  the  Text  Display  Template.  Figure  B-3  illustrates  an 
actual  implementation.  Figure  &-4  shows  an  example  of  logical  and  physical 
signals  and  their  relationships  in  the  same  Hie. 
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ICES  ELECTRICAL  ENTITY  DESCRIPTIONS 

The  following  entities  Gn  entity  numoer  order)  ere  the  subset  of  ICES  entities  which 
have  particular  meanings  when  used  for  electrical  product  data. 

100  Circular  Arc  Entity 

The  electrical  use  of  this  entity  is  in  the  geometric  representation  of 
component  parts  and  their  symbolic  representations.  In  such  usage,  it  is 
generally  part  of  a  subfigure.  It  may  be  used  as  a  join  entity.  Its  use  may  be 
defined  by  a  Levei  Faction  property  or  DE  Level  field. 

102  Composite  Curve  Entity 

The  electrical  use  of  this  entity  is  in  the  geometric  representation  of 
component  parts  and  their  symbolic  representations.  In  such  usuage,  it  is 
generally  part  of  a  subfigure.  It  may  be  tsed  as  a  join  entity.  Its  use  may  be 
defined  by  a  Level  Function  property  or  DE  Level  field. 

106  Copious  Data  Entity 

Forms  11,  12,  and  13  of  this  entity  may  be  used  to  implement  the  electrical 
join  G.e.,  schematic  or  wiring  diagram  circuit  connection  lines).  Any  of  these 
forms  may  point  to  a  Line  Widening  property.  Examples  of  this  entity- 
property  combination  are  circuit  paths  on  a  PC  board  or  IC  metaiization,  or  as 
a  bus  in  a  schematic.  Form  63,  Simple  Closed  Area,  may  be  used  to  define  an 
auto-router  restriction  area  or  a  PC  (or  IC)  defined  area  having  special 
attributes. 

108  Plane  Entity 

Certain  layers  of  PC  design  are  designated  as  "ground",  "power",  or  "heat 
sink",  and  as  such  are  large  conductive  areas.  These  layers,  as  well  as  larger 
Cirved  or  rotnded  conductive  areas  on  other  layers,  are  best  defined  by  the 
Plane  entity.  Note  that  the  form  number  indicates  whether  the  bounded 
region  is  positive  or  void  G.e.,  copper  clad  area  or  cutout). 
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110  Line  Entity 

The  Line  entity  his  several  important  uses  in  the  electrical  application.  It 
may  be  used  to  construct  component  outlines,  and  to  represent  both  logical 
and  physical  connections  (as  a  join  entity).  As  a  physical  join  entity,  the  Line 
Widening  property  will  most  often  be  attached,  giving  the  width  of 
metalization  to  be  etched  on  the  board.  As  a  logical  join  entity,  the  line  will 
mast  typically  be  used  without  the  Line  Widening  property. 

116  Point  Entity 

The  point  entity  is  used  to  locate  features  that  do  not  participate  in  electrical 
connectivity,  for  example,  a  mounting  hole. 

12d  Transformation  Matrix  Entity 

A  Transformation  Matrix  may  be  used  to  route  subfigures  to  other  than 
normal  (top  up)  positions.  Generally,  rotations  are  about  the  Z  axis  for  PC  and 
1C  constructs,  but  may  be  about  any  axis  lor  30  cabling  files. 

123  Flash  Entity 

The  Flash  entity  may  be  used  to  represent  a  repetitive  artwork  feature  which 
is  usually  produced  by  photo-optical  means.  Examples  include  PC  pads, 
targets,  clearances,  and  IC  features. 

132  Connect  Point  Entity 

The  Connect  Point  entity  is  used  to  represent  a  point  of  connection.  A 
subfigure  defining  an  electrical  component  typically  uses  the  Connect  Point 
entity  to  represent  a  pin  of  the  logical  or  physical  component  or  symbol.  A 
Connect  Point  may  also  be  used  in  a  'stand-alone"  mode,  representing  a  via 
hole,  for  example. 
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212  General  Note  Entity 

A  General  Note  is  used  to  display  constant  test.  Design  notes  would  require  a 
General  Note,  lor  example. 

302  Associativity  Definition  Entity 

When  the  originating  system  provides  for  a  relationship  not  included  among  the 
ICES  predefined  associativities,  this  entity  is  required.  Possible  uses  are  to 
relate  subfigures  to  entities  in  other  databases  (e.g.,  circuit  analysis  or  text 
requirements)  or  for  back-annotation  purposes. 

312  Text  Display  Template  Entity 

Form  O.  absolute,  Form  l:  incremental 

The  Text  Display  Template  may  be  used  to  display  text  which  may  be  unique  in 
each  instance  of  the  defined  entity  (A  pin  number,  for  example). 

320  Network  Subfigure  Definition  Entity 

For  PC  and  Cable  usage,  a  subfigure  usually  represents  a  component  and  its 
required  PC  constructs.  This  entity  is  normally  a  library  physical  or  logical 
figure  in  the  originating  system. 

UC2  Associativity  Instance  Entity 

This  entity  relates  other  entities  within  a  file  to  provide  a  "set"  with  a 
common  meaning.  Those  associativities  which  are  predefined  by  ICES  are 
identified  by  ICES  form  numbers  (e.g.,  form  IS:  Flow).  The  user  defined 
associativities  are  defined  by  an  entity  302  and  its  form  number. 

*06  Property  Entity 

The  use  of  a  property  to  indicate  the  meaning  or  purpose  of  a  geometric  entity 
applies  to  electrical  construes  as  well  as  general  graphics.  A  Connect  Point 
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entity  may  point  to  the  Drilled  Hole  property.  A  Plane  entity  or  Simple 
Closed  Area  entity  may  point  to  the  Region  Restriction  property.  Any 
property,  however,  may  point  to  the  Text  Display  Template,  with  the  text 
string  specified  in  the  property.  In  this  case,  the  Text  Display  Template 
locates  the  text  display.  This  entity  is  an  open-ended  list  allowing  for 
expansion  to  address  future  needs  such  as  simulation,  testing,  inspection 
applications,  and  extensions  into  electricai/electronic  systems  hierarchical 
design. 

412  Rectangular  array  Subfigure  Instance  Entity 
414  Circular  Array  Suofigure  Instance  Entity 

These  entities  may  be  used  to  instance  multiple  Network  Subfigure  Instances, 
but  must  not  be  used  for  instancing  Connect  Points. 

420  Network  Subfigure  Instance  Entity 

This  entity  allows  an  electrical  component  to  be  instanced  in  a  number  of 
isuque  locations.  Note  that  "ownerf*  Connect  Point  entities  must  be  instanced 
with  this  entity. 
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TABLE  1.  TBfT  TEMPLATE  VALUES  FOR  SAMPLE  SCHEMATIC 


TEMPLATE 

TLEFT 

TR1GHT 

TTOP 

TBOT 

WIDTH 

.10 

.10 

.10 

.10 

HEIGHT 

.13 

.13 

.13 

.13 

SLANT  ANG. 

0. 

0. 

0. 

0. 

ROTH.  ANG. 

0. 

0. 

0. 

0. 

MIRR.  FLG 

0 

0 

0 

0 

VRT/HORZ 

0 

0 

0 

0 

OE  FORM  NO. 

21 

21 

21 

21 

X  (DX) 

-.09 

-.03 

+  .03 

+  .03 

T(DY) 

+.03 

+  .03 

-.15 

+  .1 

2  (OZ) 

0. 

0. 

0. 

0. 

U1 

U2 

U3 

Pl-Pg 

Pl-PB 

P1-P4 

P9-P18 

P9-P18 

P9-P12 

P13-P16 

PS-P8 

PINS  USING 
THE  TEXT 
TEMPLATES 


U1  12 


iallsMl3 


12 

11 

10  GNO 


•— \  WIDTH  i-— 


DT  I _ T 

D  DX  i 


Flour*  B-2  Samol*  Schematic 


Figur*  B— 4  Schamatic7Ptiysk:al  Diagram  for  Sampla  Schematic 
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TO  F.  Riddell.  R.  Gunkel 

FROM  :  ML  Brei 


research  to  test  and  demonstrate  the 

CONCEPTUAL  INFORMATION  MODEL  FOR  ELECTRONIC  EQUIPMENT 

April  2.  1987 


A. 


INTRODUCTION 


Much  research  in  the  area  of  computer-aided 
engineering/design/manufacturing  (CAE/CAD/CAM)  software 
integration  techniques  has  occurred  over  the  last  several 
years.  This  research  has  produced  many  discrete  theories 
concerning  information  modeling  and  the  development  and 
implementation  of  neutral  data  exchange  formats.  There 
have  been  very  few,  if  any,  demonstrations  of  how  these 
theories  can  be  tied  together  for  practical  application  in 
the  CAD/CAM  domain.  With  respect  to  the  CAE  domain, 
however,  the  practical  application  of  these  theories  in  a 
global  context  is  non-existent.  It  is  time  to  test  the 
concepts  developed  and  put  the  theory  to  use  in  a  global 
context  for  CAE.  This  paper  proposes  a  project  to  prove  or 
disprove  the  viability  of  these  theories  for  solving  CAE/CAD 
software  integration  problems. 


B.  BACKGROUND 

The  proliferation  of  special-purpose  software  design 
tools  has  led  to  the  need  to  transfer  design  data  between 
disparate  engineering  databases.  Users  and  developers  of 
design  systems  seek  exchange  mechanisms  which  minimize  the 
cost  of  creating  interfaces  between  the  design  tools  and 
maximize  the  integrity  of  the  data  exchange.  When  more 
than  two  dissimilar  databases  share  data,  the  most  sensible 
transfer  mechanism  is  via  a  neutral  interchange  format. 
Users  and  developers  of  design  automation  tools  have 
committed  substantial  resources  toward  the  development  of 
neutral  interchange  formats. 

This  effort  has  resulted  in  many  formats  either  under 
development  or  currently  in  use  for  the  exchange  of  design 
data  between  CAE/CAD/CAM  tools.  One  segment  of  the 
CAE/CAD/CAM  industry,  the  electronics  industry,  is  focusing 
particular  attention  on  four  formats:  the  Initial  Graphics 
Exchange  Specification/Product  Description  Exchange 
Specification  (IGES/PDES),  the  Electronic  Design  Interchange 
Format  (EDIF) .  the  VHSIC  Hardware  Description  Language 
(VHDL),  and  the  Institute  for  Printed  Circuits  (IPC)  D-350 
series.  These  standards  are  capable  of  representing  some 
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particular  aspect  of  design  data  for  electronic  equipment. 
They  are  neutral  and  non-proprietary. 

These  standards  were  developed  to  serve  the  needs  of 
applications  specific  to  the  members  of  the  respective 
development  efforts.  For  instance,  IGES  was  originally 
developed  to  interchange  geometric  information.  This  has 
been  extended  to  include  many  other  types  of  information 
such  as  electronic  design  data.  EDIF  was  intended  for  the 
exchange  of  gate  array  and  semi-custom  design  data  between 
IC  design  organizations  and  IC  foundaries.  It  has  been 
subsequently  enhanced  to  include  additional  data  such  as 
printed  circuit  board  design  data.  VHDL  is  an  hardware 
description  language  (not  a  format)  for  system  design  and 
can  be  used  to  transfer  design  data  from  designers  to 
manufacturers  to  other  designers.  The  IPC-D~35x  formats 
describe  printed  wiring  board  (PWB)  data  for  exchange 
between  PWB  design  facilities  and  manufacturing  groups.  The 
series  has  been  extended  to  include  schematic  and  other 
electrical  descriptions. 

There  has  been  minimal  contact,  however,  between  the 
IGES,  EDIF,  VHDL,  and  IPC  organizations  during  development 
activities.  This  has  resulted  in  semantic  overlaps  between 
the  formats.  The  extent  of  overlap  between  the  standards  is 
ambiguous,  and  has  not  been  fully  analyzed.  This 

ambiguity  makes  it  difficult  to  develop  sound  and  extensible 
exchange  mechanisms  for  global  integration  projects.  The 
problem  is  made  more  complex  when  the  integration  task 
requires  the  use  of  more  than  one  standard.  Thus,  the 
interrelationships  between  the  standards  must  be 
well-defined  and  understood.  The  standards  should  be  viewed 
as  complementary  rather  than  competing.  This  perspective 
necessitates  a  formal  definition  of  the  interoperability  of 
the  standards . 

To  unambiguously  define  the  information  content 
( semantics )  of  each  standard  with  respect  to  one  another  and 
to  identify  the  areas  of  overlap,  a  common  means  of 
communication  is  necessary.  Conceptual  information  models 
which  depict  fundamental  data  elements  and  relationships 
between  those  elements  are  capable  of  representing  "the 
consensus  view  of  the  business  rules  of  an  enterprise. " 
This  is  the  genre  of  meta-language  needed  to  talk  about 
exchange  formats. 

Many  people  believe  that  a  conceptual  information  model 
for  electronic  equipment  can  be  used  as  a  basis  for  the 
analysis  of  the  areas  of  overlap  between  standard  exchange 
formats.  The  IEEE  Design  Automation  Standards  Subcommittee 
has  initiated  an  effort  to  create  a  conceptual  information 
model  for  electronic  equipment  and  to  use  that  model  to 
analyze  the  exchange  capabilities  and  interrelationships 
between  EDIF,  VHDL  and  IGES/PDES.  Ultimately,  the  analysis 


will  support  a  formal  definition  of  the  interfaces  between 
the  standards.  This  is  a  very  ambitious  project. 


The  information  model  for  electronic  equipment  will  be 
incorporated  in  a  large-scale  conceptual  information  model 
for  product  data  under  development  by  the  PDES 
organization.  This  global  conceptual  model  will  be  used  as 
the  foundation  of  the  PDES  format. 

The  development  of  the  PDES  conceptual  data  model  is 
proceeding  slowly.  This  is  due  to  the  highly  theoretical 
and  abstract  nature  of  the  concept  and  the  methodology. 
Information  modeling  for  engineering  product  data  is  still 
in  the  research  stage.  Issues  yet  to  be  resolved  include: 

1.  What  is  a  conceptual  model  for  engineering  product 
data? 

2.  What  is  the  most  appropriate  modeling  language  and 
methodology? 

3.  What  computerized  tools  are  necessary  to  support 
the  modeling  methodology  and  the  use  of  the 
conceptual  model? 

The  process  of  creating  a  conceptual  data  model  for 
engineering  applications  requires  many  expert  participants 
(such  as  electrical  and  mechanical  engineers)  committed  to 
the  effort  and  committed  to  providing  rigorous  attention  to 
minute  details.  This  commitment  will  not  occur  until  the 
CAE  industry  clearly  understands  the  utility  of  the 
conceptual  information  model  and  the  neutral  exchange 
formats  as  a  foundation  for  CAE  integration. 

This  gap  could  be  bridged  by  testing  and  demonstrating 
the  use  of  conceptual  information  models  and  neutral  data 
exchange  formats  to  solve  CAE  software  integration  problems. 
This  demonstration  will  serve  as  a  communication  device 
between  a  vast  array  of  players  (engineers,  modelers, 
standards  developers,  CAE/CAD/CAM  vendors.  government 
representatives,  politicians,  budgeteers,  etc.) 

The  objectives  of  the  test/demonstration  system  are  to: 

1 )  show  how  one  can  take  advantage  of  conceptual  models 
and  neutral  exchange  formats  to  integrate  heterogeneous 
CAE  design  tools, 

2)  exercise  a  selected  subset  of  the  capabilities  of  the 
neutral  exchange  formats  fcr  electronics  design  data, 
and 

3)  identify  critical  issues  for  selecting  information 
modeling  languages  and  methodologies. 
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CAL  POLY  TASK  TEAM  STATUS  REPORTS, 
9  JANUARY-27  FEBRUARY  1987 


CAL  POLY  TASK  TEAM 


Developing  a  view  in  both  directions: 
the  conceptual  data  of  electrical  products 
IEEE  •  Academia  •  Industry 


California  Polytechnic  University 
Dept  of  Electrical  &  Computer  Engineering 
3801  W.  Temple  Avenue- 
Pomona,  CA  91768-4065 
(714)  869-2511 


STATUS  REPORT 
9  January,  1987 

A  nucleus  of  the  team  met  during  this  week  to  receive  t-aining  on  the  Air 
Force  "IDEF"  modeling  methodology  and  purpose.  Excellent  instruction  was  pro¬ 
vided  by  Roger  Gale  and  Jim  Savage  of  0.  Appleton  Company. 

We  also  looked  at  the  computer  resources  to  help  us  in  the  data  administra¬ 
tion  and  model  normalization  tasks.  Here,  we  are  fortunate  to  have  a  good  DBMS 
to  store  and  manage  data  of  the  model,  the  software  tool  JANUS  installed  at 
Arizona  State  University  for  model  verification,  and  MACdraw  for  on-the-spot 
model  views  capture.  We  feel  we  have  gained  an  understanding  of  a  methodology 
for  constructing  a  conceptual  data  model,  and  that  model's  solution  to  the 
problem  of  our  CAE  environment. 

The  intensive  full-time  modeling  period  which  begins  January  19th  will  be 
in  Room  129  of  the  Electrical  Engineering  Building.  Our  expert  team  will  include 
people  from  Westinghouse,  McDonnell  Douglas,  General  Dynamics,  BITE,  and  View  Logic 
Systems.  We  deeply  appreciate  the  generous  contribution  to  this  effort  from  these 
companies.  Any  additional  firms  which  can  also  contribute  team  membership  are 
encouraged  to  do  it,  particularly  the  February  9-27  session.  Call  the  ECE  Depart¬ 
ment  for  details  or  attendance  information. 

Some  of  the  issues  relating  to  publishing  our  model  were  discussed.  Hopefully, 
one  of  the  IEEE  Proceedings  will  be  targeted.  There  are  also  at  least  two  industry 
“testbed*  database  systems  in  which  the  model  will  be  converted  into  an  operational 
environment  and  tested.  The  latter  activity  will  follow  our  team's  effort  and  may 
not  be  includable  in  our  findings. 

Don't  forget  our  major  review  dates: 

March  10-13  Boston  Area  Review  and  Workshop 
March  23-27  Bay  Area  (Livermore)  Review  and  Workshop 

April  13-17  Wri ght-Patterson  AFB  Presentation  and 

Mappings  Workshop 

Check  issues  of  the  applicable  area  IEEE  “Bulletin"  for  announcements.  We  will 
have  telephone  numbers  to  call  in  the  next  Task  Team  letter. 


Richard  Cockrum 

ECE  Department  Chairman 
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Dept  of  Electrtcal  A  Computer  Englneenng 
3801  W.  Temple  Avenue 
Pomona.  CA  91768-4065 
(714)  869-2511 


STATUS  REPORT 
January  23,  1987 


Please  note  the  following  correction  to  the  January  9  status 
report : 

The  date  of  the  Wright-Patterson  AFB  Presenta¬ 
tion  was  incorrectly  recorded  as  April  13-27. 

The  correct  dates  are  April  13-17,  198 1 . 

We  do  not  yet  have  telephone  numbers  for  you  to  contact  regard¬ 
ing  reservations  for  the  review.  We  will  publish  them  as  soon 
as  they  become  available. 

The  Team  has  constructed  an  entity  pool  from  two  printed 
wiring  assembly  models,  the  IGES  connectivity  entities,  the  EDIT 
glossary,  and  the  data  model  of  EDIF  produced  in  the  U.  K. 
(The  EDIF  data  model  was  clarified  by  comments  of  Dr.  David 
Chalmers  of  STC  Ltd.,  who  joined  the  Team  on  Friday,  January 
23.)  Most  of  the  source  list  entities  were  associated  with  about 
half  as  many  conceptual  model  data  entities.  The  entity  pool 
will  be  expanded  next  week  as  the  Team  reviews  the  VHDL  (VHSIC 
Hardware  Description  Language)  documents,  the  IEC  (International 
Electro-Technical  Committee)  Electrical  Component  Library  De¬ 
finition,  and  several  other  source  documents. 

The  "functional-connectivity"  portion  of  the  data  model  has 
been  greatly  modified  as  a  result  of  the  new  entity  definitions. 
The  division  of  functional  connectivity  and  physical  connec¬ 
tivity  has  also  affected  the  model  structure.  The  new  func¬ 
tional  view  will  be  integrated  with  the  "truth  table"  view  as  an 
entity-relationship  model.  This  part  of  the  model  will  then  be 
set  aside  until  other  parts  of  the  model  are  constructed  so  that 
keys  (i.e.,  key  attributes  of  the  entities)  and  their  migration 
can  be  completed  on  the  whole  model. 

The  Task  Team  welcomes  the  interest  of  the  Air  Force  EIS 
Program  Office  and  would  also  welcome  any  interest  by  those 
wishing  to  join  this  exciting  activity  for  the  second  full-time 
technical  modeling  session,  February  9  to  February  27,  1987,  at 
the  Cal  Poly  campus  in  Pomona,  California. 

AAdUrr* tM,  4al 

Richard  Cockrum 

ECE  Department  Chairman 
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STATUS  REPORT 
6  FEBRUARY  1987 


1 .  The  Electrical  Function  Model  was  revised  this  week  to  show  that  a  Functional  Unit  Output  Signal 
Requirement  may  be  related  to  more  than  one  Specified  Functional  Unit  Input  State.  This  is  the 
model  of  the  truth  table  which  states  that  several  different  input  combinations  will  produce  the  same 
output. 

2.  We  have  spent  considerable  time  studying  the  VHDL  documentation  with  an  interest  in 
understanding  it  and  discovering  conceptual  data  entities  and  attributes  which  should  be 
incorporated  into  our  model.  Our  thanks  tor  some  topical  clarification  from  Erich  Marschner  of  CLSI, 
Inc.  by  telephone  today. 

We  have  modeled  two  separate  ideas  which  we  have  named  Network  and  Signal.  The  Network  is  a 
name  for  the  idea  of  functional  connections.  Signal  is  a  name  ior  a  difference  in  potential  between  two 
Networks.  We  have  an  idea  named  Node  which  represents  a  place  where  a  function  of  a  Functional 
Unit  may  be  accessed.  A  Network  is  a  connected  set  of  Nodes. 

VHDL  appears  to  use  Signal  to  represent  what  we  have  called  Network.  For  purposes  of  simulation,  in 
VHDL  values  (i.e..  voltages)  can  be  assigned  to  Signals.  Different  values  can  be  assigned  to  the  same 
Signal  name  at  different  times.  VHDL  has  a  concept  of  Port.  A  Port  seems  to  correspond  to  our 
Node.  VHDL  distinguishes  between  Formal  Port  and  Actual  Port,  A  Formal  Port  is  a  place  of  access 
to  a  Design  Entity.  When  a  Design  Entity  is  ’instantiated"  (used  in  relation  to  some  other  Design 
Entity),  a  Formal  Port  becomes  an  Actual  Port.  The  Actual  Port  must  be  assigned  a  name  (which  may 
be  the  same  as  its  Formal  Port  name). 

As  of  this  week  we  have  a  concept  that  a  Node  may  be  part  of  more  than  one  Network.  For  example, 
when  tri-state  devices  are  involved,  a  device  is  sometimes  functionally  connected  and  sometimes  not. 
This  means  that  Networks  are  dynamically  defined  depending  upon  the  state  of  the  devices.  When 
we  develop  the  physical  design,  we  will  have  a  mapping  from  the  logical  Networks  to  the  physical 
connections  of  devices.  At  the  moment  we  are  thinking  of  the  physical  connectivity  as  being  named 
a  Path.  Our  present  thoughts  are  that  a  Path  may  map  to  more  than  one  logical  Network.  This  is  pan  of 
our  solution  to  our  intent  to  make  clear  distinctions  between  the  functional  requirements  view  and  the 
physical  solution  view. 

VHDL  contains  the  idea  of  a  Bus.  An  Individual  signal  can  be  declared  to  be  a  Bus,  which  means  that  it 
may  have  more  than  one  driver.  VHDL  provides  for  a  user-defined,  bus  arbitration  rule  which  will 
define  how  to  determine  what  is  present  on  the  Bus,  or  the  effective  connectivity  at  any  particular 
moment  in  time. 

As  of  this  report  the  only  time  requirement  provided  in  our  model  is  the  constraint  on  when  an  output 
signal  should  be  present  after  an  input  state  has  been  established  (Functional  Unit  Output  Signal 
Propagation  Delay  Specification).  VHDL  shows  that  we  probably  need  to  understand  and  model 
requirements  and  specifications  as  they  relate  to  time. 
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CAL  POLY  MODELING  TEAM 
STATUS  REPORT  AS  OF 

February  6,  1987 


The  conceptual  data  model  is  limited  to  defining  the  meanings  of  data  and  relational  integrity 
constraints  among  data.  It  provides  a  model  snowing  where  data  belongs  after  actions  of  people, 
machines  or  computer  programs  have  brought  the  data  into  existence.  The  data  model  is  not 
intended  to  capture  the  rules  under  which  actions  must  be  performed.  VHDL  has  a  larger  scope  and  is 
not  limited  to  defining  conceptual  data.  It  also  defines  some  of  the  rules  tor  actions  which  result  in  data 
and  for  operations  upon  that  data. 

3.  In  VHDL.  we  find  the  use  of  a  'Port'  to  apply  an  environmental  requirement  (temperature).  This  has 
caused  us  to  wonder  where  in  the  general  data  model  we  should  find  all  of  the  environmental 
requirements. 


Richard  Cockrum 

Chairman 

ECE  Department 
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STATUS  REPORT 
13  FEBRUARY  1987 


1.  All  three  model  reviews  have  been  established.  A  'news  release'  is  attached  for  your  consideration, 
and  please  feel  tree  to  pass  a  copy  along  to  your  favorite  editor. 

2.  There  was  a  discussion  about  the  identification  of  a  Functional  Unit.  There  was  an  opinion  that  it 
probably  is  a  name.  We  were  concerned  about  the  uniqueness  of  a  name.  The  discussion  led  to  fhe 
ideas  that  a  Functional  Unit  is  identified  not  only  by  its  name  but  also  by  the  identification  of  the 
Enterprise  which  spawned  it.  Further  discussion  proposed  that  there  is  another  limiting  context 
needed.  This  is  the  idea  which  seems  to  be  represented  by  'Project',  'Product  Line'.  "Product 
Model"  and  similar  ideas.  A  concatenation  of  Enterprise  ID,  Context  ID  and  Functional  Unit  Name 
should  be  unique.  We  have  drawn  a  small  FEO  to  illustrate  this  idea. 

3.  An  idea  was  introduced  that  a  Functional  Unit  serves  to  collect  two  separate  ideas.  One  idea  is  that  of 
a  Functional  View  and  the  other  is  that  of  a  specific  'Functional  Design'.  The  Functional  Unit  may 
have  many  Functional  Views  but  zero  or  one  Functional  Design.  The  intersection  between  Functional 
Design  and  Functional  View  is  Function  Sub  Unit.  This  produced  a  lively  discussion.  We  have 
captured  this  idea  in  a  FEO. 

4.  Other  rules  differing  from  those  in  the  2/6/87  model  were  suggested  as  follows: 

A  Network  is  composed  of  Nodes  and  zero  or  one  Pons. 

A  Port  is  a  part  of  zero  or  one  Networks. 

A  Node  can  participate  in  zero  or  one  Networks. 

A  Signal  is  a  difference  of  potential  between  two  Networks  and  not  related  directly  to  Nodes. 

5.  There  was  considerable  discussion  of  the  effect  upon  the  data  model  if  we  are  capturing  the  data  of 
incomplete  functional  designs.  This  was  left  as  an  unexplored  area. 

Anyone  who  would  like  to  provide  comments  or  additional  Insights  Is  invited  to  phone 

the  team  between  8:30  am  and  4:00  pm  PST  at  (714)  869-2551  before  27  February 

1987. 


Richard  CocKrum 

Chairman 

ECE  Department 
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STATUS  REPORT 
20  FEBRUARY  1987 


1.  We  have  established  a  very  useful  notion  tor  determining  what  data  is  within  the  scope  ot  the  model. 
This  notion  is  consistent  with  and  an  extension  to  the  PDES  Product  Data  Planning  Model. 

We  have  identified  three  distinct  structures  of  data  which  evolves  over  the  product  lilecycle: 
requirements,  functional  design  solutions,  and  physical  design  solutions  (green  stuff,  blue  stuff,  and 
red  stuff  respectively).  The  breakdown  of  design  requirements  are  the  controls  on  the  'Design 
Electrical/Electronic  Product'  Activity  Model  for  the  activity,  'Perform  E/E  Electrical  Design.' This  data 
includes  the  demand  specifications  independent  of  any  particular  technology.  The  functional  design 
solutions  are  driven  by  the  demand  specifications.  These  are  the  inputs  and  outputs  ot  the  activity 
'Perlorm  E/E  Functional  Design*  and  include  the  connectivity  and  the  design  pans  list.  The 
important  distinction  between  the  requirements  and  the  solutions  is  that  the  solutions  are  expressed 
in  units  of  a  particular  technology;  whereas  the  requirements  are  technology-independent.  The 
physical  design  solutions  define  the  breakdown  of  the  physical  characteristics  of  the  design  solution 
to  the  requirements. 

The  soope  of  our  model  includes  all  of  the  blue  and  red  stuff  (functional  design  solutions  and  physical 
design  solutions).  We  understand  the  importance  of  capturing  the  green  stuff  (the  demand 
requirements)  in  the  conceptual  model  but  will  tackle  this  data  at  a  later  date.  Our  first  priority  is  to 
capture  the  blue  stuff.  In  whatever  time  remains,  we  will  look  into  the  red  stuff. 


2.  The  structure  of  the  model  has  been  modified  to  reflect  the  discussions  and  resolutions  which  have 
occurred  during  the  team  meetings.  The  model  is  ready  for  a  public  review.  The  entity  and  attribute 
glossaries  are  consistent  with  our  current  understanding  of  the  model. 


3.  We  are  now  putting  together  the  presentation  materials  tor  the  review  sessions  and  organizing  the 
source  material  that  we  have  collected.  The  next  step  is  to  determine  what  we  hope  to  accomplish 
during  the  model  reviews,  and  what  should  be  at  the  completion  of  the  reviews. 


Richard  Cockrum 

Chairman 

ECE  Department 
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We  have  reached  a  significant  milestone  in  our  efforts.  We  have  come  to  the  end  ot  the  initial 
modeling  phase  and  are  ready  to  present  the  results  of  our  work  for  review  and  validation. 

We  have  made  much  progress  during  the  six  weeks  of  the  full-time  effort.  This  includes  the  analysis 
of  several  data  transfer  formats  lor  electronic  design  data,  the  review  of  three  existing  corporate  models, 
and  the  oentHication  of  conceptual  entities.  The  entities  were  developed  into  a  workable  model.  We  feel 
this  model  addresses  the  central  data  issues  of  functional  product  hierarchy,  connectivity,  and  the 
input/output/delay  relationships.  The  latter  has  been  checked  carefully  to  insure  that  the  data  involved  in 
component  "truth-tables*  or  VHDL  "signal  assignment*  statements  can  be  captured  in  a  design 
implementation  form.  That  is.  the  model  captures  the  electrical  voltage  values  which  are  the  actual 
implementation  of  the  Ts  and  Ps  or  0‘s  and  I's  of  a  truth  table.  We  believe  that  the  same  entities  of  the 
model  will  also  capture  the  data  which  describes  the  behavior  ot  analog  devices. 


We  win  continue  the  development  of  the  model  with  several  activities.  The  model  is  being  input  to  a 
model  database  for  normalization  and  documentation.  The  model  will  be  presented  at  three  public 
reviews.  The  reviews  will  include  workshops  during  which  modifications  to  the  model  may  occur. 
Following  the  workshop  in  Dayton,  the  team's  final  information  model  kit  win  be  sent  to  the  team  members. 
IEEE/D ASS,  and  the  Product  Definition  Exchange  Specification  (PDES)  organization. 

The  model  win  be  vaGdated  and  its  scope  extended  through  continuing  efforts  in  related  projects 
including  the  Engineering  Information  System  (EIS),  Computer  Aided  Logistics  Support  (CALS),  and 
PDES.  Additionally,  several  companies  will  be  developing  databases  to  test  the  schema  in  a  production 
environment.  The  model  will  be  available  in  the  JANUS  program  input  language  at  the  Arizona  State 
University  "Integrated  Information  System  Support"  Lab.  The  IEEE/DASS  has  organized  an  Electrical 
Model  Working  Group,  chaired  by  Mrs.  ML  Brei,  to  continue  the  development  and  unification  of  the  model. 
Please  keep  Mrs.  Brei  advised  of  your  interests  and  any  related  work. 

We  feel  that  the  conceptual  schema  for  shared  product  data  will  be  of  great  value  in  the 
development  of  integrated  CAE/CAD/CAM  environments,  transfer  formats,  company  databases  and.  the 
longer  range  goal.  Computer  Integrated  Manufacturing  (CIM).  In  the  long-term,  less  software  will  be 
needed  to  share  data  based  on  a  common  schema. 


Rchard  H.  Cockrum 

Chairman 

ECE  Department 


I 
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TO  :  F.  Riddell.  R.  Gunkel 
FROM  :  ML  Brel 

SUBJ  :  Cal  Foly  Task  Team  Trip  Report 
DATE  :  January  30.  1987 


CAL  POLY  TASK  TEAM  SESSION  1 
January  5-9.  1987 


1.  The  Cal  Poly  Task  Team  met  during  the  week  of  January  5.  1967  at 
the  California  State  Polytechnic  University  in  Pomona,  California. 
Professor  Richard  Cockrum  of  the  Department  of  Electronics  and  Computer 
Engineering  is  the  point  of  contact  (714-869-2511). 


2.  Curtis  Parks  (General  Dynamics)  hosted  the  session.  In  addition, 
the  following  attended; 

ML  Brei  (BITE  Inc.  for  the  Institute  for  Defense  Analysis) 

Roger  Gale  (D.  Appleton  Company) 

Jerry  Kane  ( Westinghouse  Electric  Corporation,  Defense  &  Electronics) 
John  M.  Rychlewski  (Mcdonnell  Douglas  Astronautics  Company) 

Jim  Savage  (D.  Appleton  Company ) 


3.  The  purpose  of  the  week-long  session  was  to  receive  training  in  the 
IDEFl-x  methodology.  Roger  Gale  and  Jim  Savage  provided  the  team  with 
excellent  training.  See  attachment  1  for  a  list  of  reference  material 
used  during  the  training. 


4 .  The  goal  of  the  Cal  Poly  Task  Team  is  to  create  a  conceptual  data  model 
of  electrical  and  electronic  products.  The  conceptual  model  will  be  used  for 
atleast  two  purposes.  First,  it  will  be  integrated  with  the  conceptual  product 

model  under  development  by  the  Product  Data  Exchange  Specification  (PDES) 
working  groups.  The  PDES  conceptual  product  model  will  be  the  semantic 
foundation  for  the  specification. 

Second,  the  IEEE  Electronic  Modeling  Group  (EMG)  will  use  the  model  to 
evaluate  and  compare  the  extent  to  which  the  Electronic  Design  Interchange 
Format  (EDIF)  and  the  VHSIC  Hardware  Description  Language  (VHDL),  and  PDES 
expresses  electronic  design  data. 

Both  efforts  will  make  valuable  contributions  toward  the  advancement  of 
CAE  integration  strategies. 


5.  The  Cal  Poly  Task  Team  will  begin  its  first  3-week  full-time  session  on 
January  19.  The  second  session  will  begin  on  February  9.  These  sessions  will 
be  held  at  the  Engineering  Building  (714-869-2551).  Once  again,  Professor 
Richard  Cockrum  is  the  point  of  contact. 

Following  the  completion  of  the  data  model,  a  series  of  reviews  will  be 
held  to  assess  the  soundness  of  the  model  from  the  perspective  of  diverse 
sectors  of  the  design  community.  The  proposed  schedule  is  as  follows: 

10-13  MAR  67  Boston 

23-27  MAR  87  Lawrence  Livermore  Laboratory 

13-17  APR  87  Wright-Patterson  AFB 


6.  The  following  was  agreed  upon  at  the  completion  of  the  week: 

1.  SCOPE  of  the  information  model  the  information  requirements 

of  the  activity  model  derived  from  the  previous 

CAL  Poly  working  sessions  (all  design  activities  prior  to 

engineering  release  to  manufacturing). 

2.  RANGE  :  Printed  circuit  board/assembly  and  round  wire  harness 


3.  DELIVERABLES: 

A.  Data  Model  :  Diagrams,  Glossary,  Business  statements/rules 

B.  Technical  Issues  List 

C.  Periodic  status  reports 

D.  Review  kits 

E.  Final  Report  -  for  IEEE  publication 


4  .  ACTION  ITEMS : 

A.  Develop  list  of  Review  Kit  Respondents. 

B.  Contact  review  hosts. 

C.  Identify  technical  writer  (CAL  Poly  project?)  for  final  report. 

D.  Prepare  guidelines  for  review  working  meetings  and  host 

activities . 


Appendix  L 

ELECTRONICS  STANDARDS  COORDINATION  MEETING 
REPORT,  4  FEBRUARY  1987 


Record  or  the  Electronic  Standards  Coordination  Meeting 


Prepared  For 
Prepared  By 
REVISION  DATE 


The  Institute  for  Defense  Analysis 
ML  Brei,  BITE  Inc. 

February  4,  1987 


The  first  Electronic  Standards  Coordination  Meeting  was 
held  on  December  17,  1986  at  the  Institute  for  Defense 
Analysis  in  Alexandria,  Virginia.  Bruce  Lepisto,  Chairman 
of  the  CALS  Working  Group  on  Specifications  and  Standards, 
DoD  Weapon  Support  Improvement  &  Analysis  Office,  chaired 
the  meeting.  Agenda  items  follow. 


A.  OPENING  REMARKS.  Dr.  Frederick  Riddell,  The  Institute  for 
Defense  Analysis. 

The  Institute  for  Defense  Analysis  provides  a  neutral  forum 
addressing  the  needs  of  the  DoD  community.  In  this 
capacity,  it  has  contributed  to  several  DoD  Computer  Aided 
Logistics  Support  (CALS)  activities. 

The  success  of  the  CALS  program  hinges  on  the  identification 
of  a  set  of  standards  for  the  interchange  of  technical 
product  data  in  digital  form  and  the  definition  of  the 
relationships  among  those  standards . 

The  purpose  of  this  meeting  was  to  begin  the  process  of 
exploring  issues  concerning  data  interchange  standards  for 
electronic  equipment  by: 

1)  dist issing  the  interaction  of  the  standards  in  terms 
of  DoD’s  CALS  requirements,  and 

2)  reaching  an  agreement  on  an  appropriate  approach  for 
resolving  the  standards  overlap  issue. 


B.  CALS  OVERVIEW.  Bruce  Lepisto. 

The  goal  of  the  CALS  program  is  to  implement  a  near 
paperless  environment  for  the  delivery  and  use  of  logistic 
technical  information.  This  requires  integrating  the 
design,  manuf acturing,  and  logistic  support  functions  by 
linking  together  automation  tools. 
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To  accomplish  this,  a  management  structure  consisting  of 
both  DoD  and  industry  groups  to  design,  develop,  and 
implement  CALS  has  been  put  into  place;  weapon  a/stem 
contract  deliverables  and  functional  requirements  are  being 
identified;  and  an  aggressive  schedule  has  been  set. 

Each  service  released  implementation  plans  in  July  1986.  In 
September  1986,  the  DoD  development  strategy  for  CALS  was 
published.  The  DoD  CALS  implementation  plan  will  be 
available  in  January  1987. 

To  accomplish  a  phased  implementation  strategy,  a  series  of 
Core  Requirements  Packages  will  be  produced.  The  initial 
requirements  will  address  the  use  of  existing  technology  and 
standards  to  apply  CALS  capabilities.  '’’hus ,  during  the 
first  phase  the  focus  will  be  on  what  can  be  done  today.  In 
the  longer  term,  the  emphasis  will  shift  to  extensive  system 
redesign. 


C.  PHASE  I  CORE  REQUIREMENTS .  Bruce  Lepisto. 

The  first  phase  Core  Requirements  will  contain  management 
guidance  for  implementing  CALS  programs.  This  guidance 
includes  standards  for  data  interchange  and  communication; 
requirements,  contractual  terminology  and  application  and 
user  guidance.  The  following  schedule  has  been  set  for  the 
development  of  this  package: 

87  FEB  Draft  Phase  1.0  Core  Requirements  completed. 

Contains  a  placeholder  for  the  electronic 
equipment  standards . 

87  MAY  Phase  1.0  Core  Requirements  released  as  DoD  policy 
and  distributed  to  the  services  and  the  Defense 
Logistics  Agency  (DLA)  for  action. 

87  SEP  Draft  Phase  1.1  Core  Requirements  released.  This 
version  will  contain  a  definition  of  where  and  how 
the  data  interchange  standards  for  electronic 
equipment  should  be  used  in  DoD  weapon  system 
procurements . 

+5  yrs  Implementation  of  Phase  II  of  CALS,  involving 

extensive  DoD  and  industry  data  system  redesign  to 
provide  an  integrated  digital  support  environment 
for  weapon  system  design,  manufacturing,  and 
logistics . 
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D.  EDIF  OVERVIEW.  Mike  Waters,  Chairman  of  the  EDIF  Technical 
Committee . 

1.  Background. 

The  Electronic  Design  Interchange  Format,  EDIF,  facilitates 
the  movement  of  electronic  design  data  between  sophisticated 
databases  in  a  commercial  environment.  This  provides  links 
between  disparate  systems  and  corporate  control  over 
information  content. 

The  EDIF  development  philosophy  consisted  of  five  tenets: 
five  years  is  too  late;  less  talk  and  more  work  is  required; 
keep  it  simple;  make  it  extensible  and  upwardly  compatible; 
and  do  not  create  a  design  language  or  database.  EDIF  is 
intended  for  the  representation  of  IC  and  electronic  design 
data,  not  mechanical  design  data. 

The  EDIF  organization  was  founded  on  November  13,  1933  at  UC 
Berkeley.  At  this  time,  six  companies  and  one  university 
agreed  to  contribute  on-going  man-power  toward  the 
development  of  the  format. 

2.  Organization. 

a)  Steering  Committee:  makes  policy  decisions  and  establishes 
business  relationships  between  concerned  corporations. 

b)  Technical  Committee:  coordinates  the  work  of  the  technical 
subcommittees  and  is  responsible  for  the  technical  content 
of  the  specification. 

c)  Technical  Subcommittees:  consist  of  specialists  who  make 
recommendations  to  the  Technical  Committee. 

3.  European  Interest. 

Participation  in  EDIF  activities  spans  the  D.S.,  Europe  and 
East  Asia.  User  Groups  have  been  formed  in  the  OS,  the  OK, 
and  Germany.  There  are  both  OS  and  European  technical 
subcommittees . 

4.  Affiliations. 

a)  An  agreement  to  join  the  EIA/JEDEC  will  be  signed  in 
December,  1986. 

b)  The  EDIF  Evaluation  and  Analysis  Group  has  been  formed  under 
the  IEEE  Design  Automation  Technical  Committee  (DATC/DASS). 

c)  EDIF  was  recommended  for  use  at  the  January  1986  Engineering 
Information  System  (EIS)  Seminar  in  Arizona. 


5.  Capabilities/Changes. 


EDIF  is  capable  of  representing  the  electrical 
characteristics  necessary  for  implementation  of  electronic 
products.  It  can  express  library/cell  organization;  provide 
extensive  date/version  control;  describe  the  cell  interface, 
cell  details  (contents),  and  technologies;  and  represent 
timing,  geometry,  and  physical  objects.  Changes  for  version 
2.00  (targeted  for  early  1987)  include  a  number  of 
extensions,  changes,  and  refinements  to  the  format. 


6.  Overlap. 

EDIF  addresses  the  IC  description  necessary  for  fabrication. 
This  includes  modeling  and  behavioral  aspects  and  some 
printed  circuit  board  descriptive  material. 

IGES  targets  the  full  printed  circuit  board  design  function 
as  an  extension  to  its  mechanical  description  (ref.  NCGS 
meeting  30  Jan  86). 

VHDL,  a  high-level  functional  design  language,  addresses 
systems  level  descriptions/simulation.  It  is  not  intended 
for  physical  design  data.  Thus,  rather  than  overlapping 
with  EDIF,  it  is  complementary. 


E.  IGES  OVERVIEW.  Brad  Smith,  IGES  Chairman. 

1 .  Background . 

Work  on  the  Initial  Graphics  Exchange  Specif icaticn  (IGES) 
began  in  September  1979.  IGES  1.0  was  published  as  a 
National  Bureau  of  Standards  (NBS)  report  in  January  1980. 
It  was  recommended  for  standardization  by  the  American 
National  Standards  Institute  (ANSI)  subcommittee  Y14.26  in 
May  1980  and  approved  as  ANSI  standard  Y14.26M  in  September 
1981. 

The  most  recent  version  of  the  standard,  Version  3.0,  was 
published  in  April  1986.  It  has  been  submitted  to  the  ANSI 
Y14.26  committee  and  will  be  published  as  ANSI  standard 
Y14.26M  by  the  summer  1987. 

The  IGES  3.0  is  about  530  pages  long.  IGES  4.0  will  be 
released  in  the  spring  1987. 

2.  Organization. 

a)  Steering  Committee:  makes  strategy  and  policy  decisions. 

b)  Technical  Planning  Committee:  plans  and  coordinates 
technical  activities. 
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c)  Edit  Committee:  is  responsible  for  the  various  IGES 
products. 

d)  Technical  Committees  of  the  General  Assembly:  focus  on 
special  interests  within  the  IGES  projects. 

3.  PDES. 

The  IGES  Organization  is  also  pursuing  the  development  of 
the  Product  Data  Exchange  Specification  (PDES).  This  is  an 
R&D  effort,  underway  for  2  years,  addressing  a  different 
technology  base  than  the  IGES  format.  IGES  is  intended  for 
information  exchange  between  databases  that  must  be 
interpreted  by  human  beings.  PDES  is  a  complete  database 
exchange  that  does  not  require  human  interpretation. 

The  complexity  of  these  projects  is  enormous.  This  is  due 
in  part  to  a  need  for  building  in  flexibility  for  future 
growth. 

To  handle  the  complexity,  PDES  will  be  developed  using  a 
3-layer  architecture  (which  divides  the  problem  into  3 
parts:  logical,  conceptual  and  physical).  This  architecture 

is  being  realized  by  using  the  ICAM  Definition  (IDEF)  and 
NIAM  modeling  techniques. 

Information  models  are  being  developed  for  specific 
application  areas  (mechanical  products;  electrical  products; 
architecture,  engineering,  and  construction;  finite  element 
modeling;  and  drafting)  and  constituent  technical  areas 
(manufacturing  technology;  solid  modeling;  curve  and  surface 
modeling;  and  presentation  data) . 

The  results  of  this  work  will  be  a  roadmap  for  building 
exchange  standards  which  are  easy  to  implement,  precise, 
less  ambiguous,  and  easily  testable  (i.e.  proving  the 
implementation  correct  and  complete). 

The  PDES  initiation  activities  have  been  published  and  a 
testing  documeut  will  be  ready  by  April  1987. 

PDES  is  the  OS  contribution  to  the  international  Standard 
for  the  Exchange  of  Product  Data  (STEP)  development  effort. 
The  goal  is  to  develop  a  single  international  standard  for 
complete  product  data  exchange . 

4.  Electrical  Applications  Committee:  Larry  O’Connell,  Chairman 
jf  the  Electrical  Applications  Committee. 


h'  O’Connell 
package  and 
requ: remento 
Included  -.n 
capability , 


ye'  iewed  the  matrix  sent  with  the  invitation 
ider  :ified  IGES  capabilities  that  meet  CALS 
as  outlined  by  the  information  categories, 
the  list  are  3-D  graphics,  full  drawing 
full  connectivity,  technical  publications 


capability,  associativity  (such  as  identifying  level  of 
spares),  and  subfigures  (to  treat  discrete  units  as  groups). 


IGES  Version  4.0  will  include  the  capability  to  attach 
attributes  for  reliability  and  maintainability 
considerations . 


F.  IPC  OVERVIEW.  Dieter  Bergman,  IPC  Technical  Director. 

1.  Introduction. 

The  Institute  for  Printed  Circuits  (IPC)  is  a  trade 
organization  formed  in  1957  by  six  board  manufacturers  who 
were  dissatisfied  with  existing  organizations.  Currently  it 
has  1400  member  companies,  28%  of  which  are  regular  members, 
35%  are  allied  members,  31%  are  associate  members,  and  6% 
are  government  and  technical  liaisons.  The  organization 
focuses  on  both  national  and  international  concerns. 

The  IPC  standard  of  interest  to  the  CALS  program  is  the 
IPC-D-350  series.  Originally,  IPC-D-350  was  developed  in 
1971  to  provide  complete  manufacturing  data  to  produce 
unpopulated  printed  circuit  boards.  This  includes 
single/double-multilayer  boards,  conductor  definitions,  hole 
information,  board  data,  electrical  data,  etc.  It  provides 
direct  conversion  through  translation  for  drilling 
equipment,  phototool  plotters,  direct  imaging  equipment, 
testers,  etc. 

2.  Implementation  History. 

IPC-D-350  was  developed  throughout  1970-71  and  released  in 
1972.  Revision  A  was  completed  in  1975  after  which  the 
first  contract  specifying  its  use  was  issued.  During  this 
time  period,  joint  industry  and  DoD  coordination  meetings 
were  held,  and  ANSI  approval  (coordinated  through  ANSI 
Y14.26)  was  granted. 

Revision  B  was  published  in  August,  1977  and  reaffirmed  in 
October  1985.  This  update  provided  more  flexibility  for 
implementation,  omitted  the  standard  font  and  land  patterns, 
and  in  general,  was  simplified  for  small  company  use.  ’t  was 
approved  for  use  by  DoD  and  became  a  requirement  for 
MIL-STD-275  and  MIL-STD-2118.  As  a  result  of  the  DoD 
endorsement,  a  5-year  no-change  policy  was  agreed  to. 

The  major  user  of  the  standard  is  the  National  Security 
Agency  (NSA).  Originally,  NSA  was  one  of  the  few 

organizations  with  the  exp->— -ise  to  receive  electronic  data 
and  they  were  willing  to  work  with  the  vendors.  NSA  has 
provided  invaluable  input  to  the  IPC  committee. 

The  standard  has  been  submitted  by  the  US  to  IEC  52  (USA) 
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1222  (International  Electric  Technico  Committee). 

3.  Long  Range  Objectives. 

Future  IPC  activities  are  focused  on  meeting  NSA/DoD 
objectives.  This  includes  producing  a  complete  definition 
of  an  electrical  assembly  from  design  to  manufacture  to  test 
to  hardcopy. 

If  necessary,  the  IPC  organization  will  change  the  language 
to  meet  the  users  needs.  The  intent  is  to  produce  a  single 
document  which  is  useful  to  industry  and  the  government. 

4 .  Problems . 

As  a  result  of  the  experience  with  NSA,  the  IPC  organization 
has  learned  that  the  following  may  hinder  the  success  and/or 
usefulness  of  a  standard: 

a)  too  much  implementation  flexibility, 

b)  minimum  support  by  CAD  system  vendors, 

c)  industry  usage  abuse, 

d)  inadequate  training/promotion/visibility, 

e)  experience  of  tri-service  personnel,  and 

f)  the  lack  of  public  domain  tools  such  as  translators . 


G.  VHSIC  Hardare  Description  Language  (VHDL)  OVERVIEW.  Dr. 
John  Hines,  AFWAL/AAD  VHSIC  Program  Office. 

1.  The  Problem. 

The  primary  problem  facing  the  electronic  design  community 
is  the  tremendous  amount  of  documentation  that  must  be 
created  during  the  design  process.  The  solution  is  to 
streamline  the  design  and  documentation  of  advanced  digital 
systems.  Existing  hardware  description  languages  are 
incapable  of  accomplishing  this  because  their  evolution  was 
not  planned. 

The  need  for  a  hardware  description  language  to  input  design 
data  became  very  apparent  by  1979.  This  langauge  would: 

-  provide  a  human  readable  design  description, 

-  support  the  communication  of  design  data  among  vendors 
(second  sourcing)  and  between  vendors  and  users  (design 
specifications) , 

-  integrate  the  activities  of  designers  working  at  different 
levels  of  abstraction,  and 

-  increase  the  re-usability  of  hardware  designs  and 
descriptions . 

In  addition  to  a  hardware  description  language,  an 
intermediate  format  is  required  to  interface  between 
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standards  and  languages . 

2.  Axioms. 

a)  Languages  are  for  communication. 

b)  Hardware  description  languages  are  languages,  not  methods. 

c)  Languages  require  standard  "practices  and  usage"  rules  for 
communication . 

d)  The  model  is  in  the  eye  of  the  beholder. 

e)  Models  must  communicate  with  other  models  (e.g.  the  designer 
communicates  with  the  manuf acturer ) . 

f)  IGES  and  EDIF  are  viewed  as  manufacturing  protocol 
standards . 

g)  No  standards  exist  for  models,  it  is  difficult  to  get 
companies  to  talk  to  one  another. 

h)  Documentation  views  require  different  types  of  data  (the 
programmer,  designer,  functional  test  activity,  and 
reprocurement  activity  are  concerned  with  different  views  of 
the  design) . 

3.  Purpose  of  VHDL. 

a)  Provides  a  standard  medium  of  communication  for  hardware 
design  data. 

b)  Represents  information  from  diverse  hardware  application 
areas . 

c)  Supports  the  design  and  documentation  of  hardware. 

d)  Supports  the  entire  hardware  lifecycle. 

4.  Origins. 

a)  June  1981.  Developed  initial  requirements  documentation 
at  a  workshop  in  Woodshole,  MA.  (Prior  to  1980,  no 
commercially-available  hardware  description  language 
existed.  Work  was  predominantly  in  academia). 

b)  June  1982.  Draft  Request  For  Proposal  (RFP)  was  issued 

for  the  development  of  VHDL  and  the  associated  set  of  tools. 

c)  March  1983.  Final  RFP  issued. 

d)  July  198?.  Final  Requirements  Documentation  released  by 

the  development  team. 

e)  August  1986.  VHDL  released  version  7.2. 


5.  Communication  of  Design  Data. 

The  vendor  provides  the  component  description  to  the  user  in 
a  design  environment  who  produces  the  layout  drawings. 

Electrical  Engineers  think  in  terms  of  transforms.  The 
primary  VHDL  model  is  the  DESIGN  ENTITY.  Input  and  output 
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ports,  signals,  and  functions  are  defined  using  the 
black-box  approach. 

6.  Standardization  Approach. 

VHDL  version  7.2  has  been  submitted  to  the  IEEE  VHDL 
Standardization  and  Analysis  Group  (VASG)  under  the  Design 
Automation  Standards  Subcommittee  (DASS) . 

A  radical  standardization  approach  was  adopted  to  avoid  the 
mistakes  made  during  the  ADA  standardization  process.  The 
key  is  to  disallow  extensive  language  revisions  during 
balloting.  A  company  was  funded  to  perform  the  formal 
analysis  of  the  language  issues  and  to  provide  formal 
support  to  the  IEEE  committee.  To  expedite  the  resolution 
of  issues  raised  by  industry,  eight  meetings  were  scheduled 
and  held  from  March  1986  through  October  1986.  During  these 
meetings  all  issues  were  resolved. 

The  draft  standard  will  be  published  by  the  end  of  December, 
1986.  This  document  will  be  distributed  widely  and  comments 
will  be  solicited.  After  the  appropriate  revisions  are 
made,  balloting  will  begin. 


7.  Participants  in  the  development  effort. 

a)  Major  CAD  companies:  ENDOT,  Daisy,  H-P,  Mentor, 
Silvar-Lisco,  etc. 

b)  Universities:  Stanford,  Virginia  Tech,  Rensaellar 
Polytech.,  etc. 

c)  Major  companies:  General  Dynamics,  Boeing,  Sperry,  IBM,  etc 


8.  Issues. 

The  primary  concern  is  language  validation.  There  is  no 
precedent  for  validating  simulators.  NBS  has  been  requested 
to  provide  metrology  (development  of  the  validation  tools) 
and  mensuration  (administering  the  validation  tests  for  the 
VHDL  environment)  services. 


H.  LOGISTICS  INFORMATION  MODEL  MATRIX.  Don  Hall. 

The  purpose  of  the  Logistics  Information  Model  Matrix  is  to 
create  a  means  of  unambiguously  identifying  the  extent  to 
which  existing  data  interchange  standards  for  electronic 
equipment  meet  DoD  logistic  application  needs.  Appendix  7 
contains  the  objectives  of  the  matrix,  ground  rules  for 
development,  an  initial  version  of  the  matrix,  examples  of 
logistics  applications,  and  suggested  development  steps. 
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Users  from  various  application  areas  will  be  asked  to  review 
the  matrix  as  it  evolves.  To  develop  short  and  long-term 
strategies,  the  matrix  will  be  examined  for  holes  and 
redundancies.  Appropriate  review  groups  include  ••  the 
testing  community,  the  RAMCAD  working  group,  and  the 
diagnostics  working  group. 


I.  OPEN  DISCUSSION. 

Is  the  matrix  approach  a  reasonable  way  for  OSD  (the  user  of 
the  information)  to  view  the  problem? 

Reactions : 


1.  The  matrix,  as  a  management  tool,  is  a  convenient  way  to 
determine : 

a)  which  standards  cover  the  required  data  elements,  and 

b)  whether  or  not  all  required  data  elements  cam  be 
represented  by  at  least  one  of  the  standards. 

2.  The  matrix  needs  much  fine  tuning  and  some  reconfiguration. 
Noticable  problems  with  the  matrix  include: 

a)  The  Tester  Independent  Software  Support  System  (TISSS)  is 
not  represented  by  the  matrix.  Testability,  on-line 
maintenance,  etc.  is  not  addressed. 

b)  The  term  "schematic",  although  well-known  by  many  members  ox 
different  communities,  has  too  many  definitions.  Thus,  it 
is  an  imprecise  and  even  dangerous  term. 

c)  A  glossary  is  needed. 

d)  A  text  story  describing  the  development  of  some  fictious 
electronic  product  should  be  written  to  understand  the 
matrix  (see  the  Case  History  under  the  Recommendations 
section) . 

e)  Several  data  element  lists  may  be  needed. 

f)  The  size  of  the  list  is  not  a  great  concern,  however,  an 
environment  dimension  may  be  required.  Aspects  of  this 
dimension  include: 

1)  performance  of  a  design  unit  and 

2)  observed,  statistical  measures  of  its  defined  parts. 

g)  Cabling  and  harnessing  should  be  a  separate  category. 

h)  Manufacturing  requirements  dictate  a  categorization  of 
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digital  data. 


3.  The  matrix  is  not  intended  to  solve  all  of  the  problems 
facing  the  electronic  design  community.  Its  focus  is  on 
logistic  applications,  although  it  share  many  information 
requirements  in  common  with  design. 

4.  The  matrix  is  a  laundry  list.  This  is  not  a  bad  start  but 
the  solution  requires  full-scale  data  modeling  efforts. 

Logistics  representatives  should  participate  in  the 
California  State  Polytechnic  University  (CAL  Poly)  task  team 
for  data  modeling  which  begins  in  January  1937. 

5.  It  may  be  appropriate  to  present  the  matrix  at  the  Design 
Automation  Conference,  June  1987;  in  Miami,  Florida.  This 
will  draw  more  participants  and  trigger  additional  reviews. 

6.  Existing  standards  should  be  reviewed  to  test  the 
completeness  of  the  matrix.  This  was  done  in  the  course  of 
preparing  the  language  requirements  document  for  VHDL. 

7.  The  information  generated  by  ITDOES  should  be  helpful. 

8.  The  development  of  the  matrix  is  feasible  in  the  proposed 
timetable  if  interim  sessions,  mailings,  and  revisions  are 
properly  managed. 

9.  OSD  has  tasked  the  NBS  to  coordinate  the  development  of  the 

matrix.  Much  work  is  already  being  done  by  standards  and 
industry  associations  which  could  be  incorporated  into  the 
matrix.  There  is  limited  funding  available  from  DoD, 

however,  to  piece  together  these  efforts.  Thus,  DoD  should 
encourage  the  continuation  of  the  voluntary  activities. 

10.  ’he  matrix  could  be  viewed  as  a  subset  of  the  EIS.  The  EIS 
program  is  concerned  with  the  design  information  problem  and 
will  be  investigating  the  interface  standards  and  the 
mappings  between  them.  For  instance,  the  mapping  between 
system  design  and  manufacturing  is  accomplished  with 
VHDL— >EDIF  or  VHDL— >IGES. 

11.  After  the  matrix  is  finished,  mapping  from  one  language  to 

another  becomes  the  critical  technical  problem.  Information 
models  will  be  required  to  examine  the  relationships  between 
the  standards.  This  may  best  be  accomplished  in  a 

university  setting. 

In  addition  to  the  matrix,  we  will  need  examples  of  how  each 
standard  represents  a  particular  type  of  data. 

Various  groups  are  in  the  process  of  defining  relationships 
among  data  exchange  standards.  For  instance,  the  VHDL 
program  will  be  defining  a  formal  mapping  between  EDIF  and 
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VHDL  as  part  of  the  final  documentation. 


J.  SCHEDULE. 


The  schedule  proposed  at  the  meeting  has  been  revised  to 
reflect  further  input.  The  following  represents  the  latest 
proposed  dates; 


17 

DEC 

86 

13 

JAN 

87 

15 

FEB 

87 

03 

MAR 

87 

16 

MAR 

87 

30 

MAR 

87 

74 

APR 

87 

01 

MAY 

87 

03 

MAY 

87 

11 

MAY 

87 

29 

JUM 

87 

2  A 

JUL 

87 

03 

AUG 

87 

26 

SEP 

37 

Matrix,  Initial  version 

Matrix,  Interim  version  complete.  Distributed  to 
the  Electronic  Standards  Coordination  Committee 
for  review. 

Matrix  version  2  complete.  Compiled  from  results 
of  the  inputs  from  the  standards  groups. 
Workshops  begin. 

Progress  Review. 

Workshops . 

Workshops . 

Matrix  version  3  complete. 

Final  workshop. 

Progress  Review. 

Matrix  version  4  presented  at  DAC.  Workshops. 
Workshop  finale. 

Final  Review  meeting. 

Phase  1.1  Core  Requirements  released. 


K.  RECOMMENDATIONS . 

1.  A  case  study  describing  the  acquisition  process  of  an 
electronic  product  from  the  CALS  perspective  should  be 
developed.  (See  attachment. ) 

2.  DoD  should  leverage  the  work  that  is  underway  by  the  various 
standards  organizations  (i.e.  the  CAL  Poly  data  modeling 
activity) . 


L.  ACTION  ITEMS. 

1.  Distribute  the  revised  matrix  by  January  13  to  the 
Electronic  Standards  Coordination  Committee  members.  (OSD) 

2.  Review,  revise,  and  return  comments  on  the  matrix,  version  2 
to  OSD,  ASAP.  (Everyone) 

3.  Prepare  the  electronic  product  case  history.  (B.  Winner) 

4.  Distribute  the  matrix  and  associated  documentation  to  the 
members  of  the  concerned  organizations.  (Everyone) 


5.  Send  materials  to  be  incorporated  into  the  matrix  to  OSD. 
(Everyone) 


6.  Send  additional  ideas  concerning  the  matrix  and  schedule  to 
OSD.  (Everyone) 

7.  Prepare  a  definitive  schedule  for  the  workshops  and  progress 
reviews .  ( OSD ) 


M.  ATTACHMENTS. 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 
9. 

10. 

11. 

12. 


"The  Life  History  of  an  Electronic  Product  from  a  CALS 
Perspective" 

Meeting  Agenda 
Attendee  List 
Mailing  List 

Memorandum  for  the  DoD  CALS  Steering  Group:  Development 
Strategy  for  CALS 

DoD  Initiatives  in  Computer  Aided  Logistic  Support 
Logistics  Information  Model  for  Electronic  Equipment 
"EDIF  Version  200  Takes  on  Production  Environment" 

EDIF  in  Europe 

Call  For  Participation:  Standards  Task  Team  Information 

Model  Development 

Vu-graph  presentation:  EDIF 

Vu-graph  presentation:  IPC 
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TO:  F.  Riddell,  R.  Gunkel 

FROM:  ML  Brei 

SUBJ :  NOTES:  The  Life  History  of  an  Electronic  Product 
DATE:  January  2,  1987 


The  Life  History  of  an  Electronic  Product  from  the 
CALS  Perspective 


A.  BACKfiBQmSL 

The  CALS  Electronic  Standards  Coordination  Committee  has 
recommended  that  a  case  study  describing  the  acquisition 
process  of  a  typical  electronic  product  be  developed.  This 
work  will  be  done  by  the  Institute  for  Defense  Analysis, 
CSED  group,  under  funding  by  the  VHSIC  Program  Office  for 
Engineering  Information  System  activities. 

This  case  study  will  provide  a  contextual  framework  for 
creating  and  understanding  the  Logistics  Information  Model 
Matrix.  It  will  serve  as  a  reference  point  to  test  the 
correctness  and  completeness  of  the  matrix  as  the  matrix  is 
conceived.  The  terminology  defined  in  the  case  study  will 
be  used  to  interprete  the  matrix. 


B.  OBJECTIVES. 

The  case  study  should: 

1.  Track  the  development  of  an  electronic  product  (consisting 
of  digital,  analog,  and  electro-mechanical  components) 
through : 

a)  conceptual  design 

b)  engineering  analysis 

c)  detailed  design  and  development 

d)  production 

e)  testing 

f)  delivery 

g)  field  support 

h)  re-design 

2.  Define  internally-consistent  terminology  for: 

a)  the  life  cycle  phases  (i.e.  the  process) 

b)  the  functions  performed  and  who  performs  them 

c)  contractor  and  defense  relationships 

d)  applicable  mil-specs 

e)  data  required  to  support  the  prime  and  sub-contractors 

3.  Describe  all  data  exchanges  required 


1.-15 


1.  Prepare  the  strawman  document  (approx.  15  pages). 

Target  completion  date:  February  15,  1986. 

a)  Describe  an  abstract  notional  system. 

b)  Identify  sources  of  information  (existing  descriptions  of 
information  flow,  military  standards  and  specifications, 
etc .  ) 

c)  Extract  applicable  information  from  the  information  sources 

d)  Prepare  results. 


2.  Distribute  strawman  document  to  OSD  and  Electronic  Standards 
Coordination  group  fcr  review  and  refinement. 


3.  Distribute  the  revised  case  study  document  to  the  user 
groups  developing  the  matrix. 


AGENDA 


December  17,  1986 

Introduction : 


0900 

Opening  Remar les 

F.  Riddell 

0915 

CALS  Purpose  and  Objectives 

B.  Lepisto 

Status,  domain  and  development  philosophy  of  each 

standard 

(10  minutes  each) 

s 

0930 

EDIF 

R.  Smith 

0940 

IGES 

B.  Smith 

0950 

IPC 

D.  Bergman 

1000 

VHDL 

J.  Hines 

1010 

Break  (15  mintues) 

Discussion  of  the 

issues : 

1025 

Overview  of  the  DoD 

Requirements  Matrix 

D.  Hall 

1100 

Discussion 

B.  Lepisto 
(moderator ) 

1200 

Lunch  (1  hour) 

1300 

Continuation  of  Discussion 

B.  Lepisto 

1500 

Plan  of  Action  and  Issues 

B.  Lepisto 

1700 

Adjourn 

i 
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ACQUISITION  ANO 
LOGISTICS 


THE  OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 

WASHINGTON.  B.C.  2010l-t000 


September  11,  1986 


MEMORANDUM  FOR  THE  DOD  CALS  STEERING  GROUP 
SUBJECT:  Development  Strategy  for  CALS 


One  of  the  primary  objectives  of  CALS  is  the  development  of 
a  unified  DoD  interface  with  industry  for  the  exchange  of 
technical  information  in  digital  form.  The  attached  paper 
outlines  a  phased  strategy  for  achieving  this  unified  interface. 
It  incorporates  your  comments  on  the  development  of  a  "core" 
package  of  common  DoD  requirements  and  standards  for  CALS 
applications,  which  can  be  tailored  and  extended  by  the  Services 
in  specific  contract  implementations.  This  broadly  defined 
strategy  should  be  incorporated  in-Service  and  DLA  CALS 
implementation  planning  now,  and  we  should  continue  our 
cooperative  efforts  to  work  out  the  details. 

We  are  planning  a  series  of  working  sessions  to  discuss 
the  content  of  this  strategy  and  to  lay  the  groundwork  for  the 
Phase  I  core  package.  As  previously  announced,  the  first  such 
CALS  architecture  planning  session  is  scheduled  for  7  October 
19R6  at  National  Bureau  of  Standards  (0900-1400  in  the  AMRF 
conference  room) .  I  would  appreciate  your  forwarding  the 
attached  paper  for  review  by  the  appropriate  implementing 
offices,  and  for  seeing  that  their  inputs  are  provided  at  the  7 
October  meeting  and  subsequent  sessions. 

Our  goal  should  be  to  have  all  comments  on  implementation  of 
this  strategy  resolved  by  7  November  for  incorporation  in  updated 
Service  and  DLA  CALS  implementation  plans  and  in  the  summary  DoD 
CALS  plan  that  we  have  targeted  for  public  release  in  December. 


£ 


[jjyf' •O'v 

Russell  R. 

Chairman,  DoD  CALS  Steering  Group 


Shorey  / 


Attachment 


Distribution ; 

Mr.  Goertzel,  DCA 
RADM  Johnson,  OP-40 
LTC  Kiggans,  DARPA 
Mr.  Knapp,  DLA 
Mr.  Mosemann,  DASAF(L) 
Mr.  Orsini,  DASA(L) 

Mr .  Rowland ,  NBS 


Copy  to: 

Mr.  Cale,  OPNAV 
Mr.  Campo ,  OASA(L) 

Mr.  Cribbins,  DCSLOG 
Mr.  Dickinson,  OASA(RDA) 
Ms.  Fountaine,  OASD(C^I) 
Mr.  Geiger,  NAVSEA 
Mr.  Goldfarb,  OASAF(RDL) 
Mr.  Heinbach,  AMC 
Mr.  Sharkey,  OASD(A&L) 
Mr.  Springett,  OASD(C) 

Ms .  Wood ,  NBS 

Mr.  Yurcisin,  OASD(AStL) 

Mr.  Appleton,  DACOM 

Mr.  Bartley,  OASD(AfiL) 

Mr.  Christianson,  AF/RDX 

Mr.  McDevitt,  DSIO 

LTC  McGinness,  DCSLOG 

Mr.  Gorham,  NAVSUP 

LTC  Williams,  AF/LEX 

Mr  .  Presker ,  DLA 

COL  Tattini ,  AFSC 

Mr.  Bettwy ,  NBS 

Mr.  Arcieri,  WSIAO  ^ 

Mr.  Lepisto,  WSIAO 

Mr.  Callen,  AMC 

Mr.  Newlin,  OUSDRE ( R&AT ) 
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CALS  Development  Strategy 


Overview 

The  overall  objective  of  CALS  is  to  integrate  and  improve 
design,  manufacturing,  and  logistics  functions  through  the 
efficient  application  of  computer  technology.  Implicit  in  this 
objective  is  a  substantial  shift  from  current  paper  intensive 
processes  to  a  highly  automated  mode  of  operation.  The  major 
CALS  challenge  is  to  develop  compatible  information  system 
architectures  in  DoD  and  industry  that  can  be  rapidly  implemented 
without  incurring  excessive  costs.  To  ensure  compatibility,  the 
Services  need  a  common  DOD  CALS  "core"  specification  as  a  point 
of  departure  for  their  system  designs  and  applications.  This 
paper  broadly  outlines  a  strategy  to  meet  that  challenge  and  to 
provide  the  direction  to  achieve  the  CALS  goal  of  a  unified  DoD 
interface  with  industry  for  digital  data  exchange. 

The  proposed  development  strategy  segments  CALS  evolution 
into  two  phases,  with  central  development  of  a  "core" 
requirements  package  for  each  phase.  Phase  I  will  focus  on  a  few 
major  logistic  applications,  and  will  use  available  technology 
and  standards  to  implement  digital  data  exchange  between  existing 
and  emerging  automated  systems  in  DoD  and  industry  by  1988. 

Phase  I  will  also  define  the  minimum  initial  functional 
requirements  for  integrating  R&M  into  the  computer  aided 
engineering  and  design  process.  Phase  II  will  rely  on  strong 
industry  involvement  for  a  broad  based  system  redesign  to 
implement  more  advanced  technology  and  more  capable  data  exchange 
standards,  and  to  support  a  wider  range  of  logistic  applications 
throughout  a  weapon  system's  life  cycle. 

Phase  I 

The  primary  Phase  I  objective  is  to  develop,  within  six 
months,  initial  "core"  CALS  requirements  packages  for  the  common 
DoD  elements  of  CALS  applications.  These  requirements  will  be 
tailored  by  the  Services  and  implemented  in  contracts  with 
industry  (both  weapons  system  contracts  and  automated  system 
contracts).  These  common  requirements  must  include  the 
functional  requirements  which  describe  data  processing, 
interactions,  and  updating  capabilities;  and  the  technical 
interface  standards  for  exchanging  data  among  contractors,  and 
between  contractors  and  DOD. 

Phase  I  requirements  will  be  commensurate  with  available 
technology  and  data  interchange  standards.  For  example,  Phase  I 
may  require  the  delivery  of  technical  manuals  in  digital  form  to 
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nodes  in  the  Service  distribution  system  for  page  image  display 
or  "on  demand"  printing,  but  the  capability  for  paperless 
interactive  display  to  end  users  may  be  deferred  to  Phase  II. 
Existing  data  exchange  standards,  such  as  those  in  the  draft 
MXL-STD-xxxx  on  Automated  Interchange  of  Technical  Information, 
will  form  a  part  of  the  Phase  I  core. 

Phase  I  will  initially  focus  on  three  key  logistic 
applications,  which  encompass  most  of  the  elements  currently 
envisioned  for  a  CALS  architecture.  These  are: 

(1)  Spares  reprocurement  (including  access  to  engineering 
drawings  and  other  needed  data) 

(2)  Development  and  delivery  of  technical  publications 
(including  updating  and  corrections) 

(3)  Development  and  application  of  Logistics  Support 
Analysis  data  (including  online  access  to  contractor 
data  systems). 

Additionally,  Phase  I  will  define  the  minimum  requirements 
for  integrating  R&M  into  the  Computer  Aided  Design/Engineering 
(CAD/CAE)  process  now  being  implemented  in  industry.  These 
initial  requirements  are  expected  to  address  the  interfacing  of 
existing  R&M  design  tools  with  CAD  data  bases,  and  providing  R&M 
analysts  online  access  to  the  same  data  base  that  design 
engineers  use. 

Phase  II 


The  Phase  II  "core"  CALS  requirements  package  and  Service 
extensions  will  take  advantage  of  advanced  system  integration 
technology  to  integrate  engineering,  design,  manufacturing  and 
the  development  of  logistics  data,  and  will  cover  the  full 
spectrum  of  life  cycle  design,  manufacturing  and  logistic 
applications.  For  example,  the  Phase  II  requirements  may 
include  such  features  as  guaranteed  consistency  of  logistic  data 
products  to  match  weapon  system  configuration,  available  online 
to  a  variety  of  users.  Phase  II  will  also  take  full  advantage  of 
data  exchange  technologies  who  difficulties  are  currently  being 
worked  out  (e.g.  exchange  of  engineering  drawings  in  vector 
form)  . 

In  the  area  of  design  for  suppor tabi lity ,  the  Phase  II 
package  would  include  common  functional  requirements  ranging  from 
the  systems  engineering  process  needed  to  allocate  and  manage 
support-related  design  characteristics  to  defining  requirements 
for  field  feedback  loops  to  assess,  correct  and  prevent  design 
related  supportability  problems.  This  will  include  integrated 
design  and  engineering  analysis  tools,  such  as  computer  aided 
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thermal  analysis,  computer  aided  failure  modes  and  effects 
analysis,  computer  aided  dependency  modeling,  computer  assisted 
parts  selection,  etc. 

Management 

Developing  CALS  requirements  that  can  be  accepted  by  all  the 
parties  involved  clearly  requires  cooperation  with  industry. 
Industry  will  be  a  major  investor  in  any  CALS  system  and 
additionally  has  unique  experience  and  expertise.  An  industry 
CALS  consortium  taking  advantage  of  the  lessons  learned  from  the 
MAP/TOP  users  group,  the  Corporation  for  Open  Systems  and  the 
Software  Productivity  Consortium,  is  the  recommended  approach  to 
getting  the  required  full  time  industry  involvement.  The  CALS 
industry  consortium  would  include  representatives  from  the  full 
range  of  industries  that  will  be  impacted  by  CALS.  This  includes 
prime  DOD  contractors,  subcontractors,  software  houses,  computer 
manufacturers,  CAE/CAD/CAM  vendors,  etc.  [Shipbuilding  may  be  a 
large  enough  area  to  sponsor  its  own  consortium  to  develop  unique 
system  applications  beyond  the  "fore".]  This  consortium  must 
have  the  resources  and  expertise  to  rapidly  develop  alternative 
cost  effective  industry  implementation  approaches  complying  with 
the  DOD  CALS  "core"  requirements  packages  and  Service  extensions. 
It  could  also  provide  verification  and  validation  services. 

The  CALS  industry  consortium's  primary  Phase  I  task  will  be 
to  develop  the  industry  "core"  implementing  specifications  to 
ensure  industry  systems  will  be  compatible  with  the  Phase  I  DOD 
CALS  requirements  and  with  one  another  (for  prime-prime  and 
vendor-prime  exchange).  To  implement  more  advanced  technology 
and  data  exchange  standards,  the  industry  CALS  consortium,  in 
cooperation  with  appropriate  industry  groups,  should  play  a  major 
role  in  developing  Phase  II  specifications  and  should  provide  the 
primary  interface  between  industry  and  DOD  in  this  area.  The 
Phase  II  implementing  specifications  would  be  in  response  to  a 
coordinated  Service  and  Agency  requirements  statement. 

In  parallel  with  efforts  to  start  an  industry  consortium, 

DoD  needs  to  get  started  on  development  of  the  Phase  I  core 
requirements  package.  The  initial  Phase  I  package  will  be 
prepared  jointly  by  the  DoD  CALS  Office  and  NBS  (with  support 
from  D.  Appleton  Co.),  in  close  coordination  with  the  Services 
and  the  NSIA  industry  task  force.  The  focus  of  this  initial 
effort  will  be  on  defining  the  intersection  of  common  DoD 
requirements  in  the  Phase  I  applications,  and  identifying  the 
standards  and  functional  capabilities  that  contractor  data 
systems  must  support.  The  Services  will  be  the  principal  source 
of  input  for  defining  these  Phase  I  core  requirements.  The 
Services  will  extend  the  core  package  in  depth  and  scope  in 
developing  their  own  implementing  specifications.  NBS  support 
will  include  assistance  in  developing  and  implementing 
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appropriate  interface  standards  and  access  protocols  as  part  of 
both  the  Phase  I  and  Phase  II  core  packages. 


Current  Service  CALS  implementation  projects,  such  as  the 
automation  of  data  repositories  and  the  automation  of  technical 
orders,  will  provide  valuable  inputs  for  Phase  I  specifications. 
Planned  Service  demonstration  efforts  and  R&D  programs  should  be 
targeted  to  validate  the  Phase  I  requirements  and  to  support  the 
development  of  Phase  II  CALS  requirements  by  demonstrating  the 
feasibility  of  advanced  technologies  and  desired  functional 
capabilities.  Additionally,  DoD's  role  in  developing 
requirements  for  integrating  R&M  into  the  mainstream  of  the  CAD 
design  process  should  be  strengthened  by  the  high  level 
involvement  of  *  :te  Service  engineering  communities. 

The  advantage  of  the  phased  approach  to  defining  core 
CALS  requirement  packages  is  the  ability  to  evolve  CALS  systems 
in  an  orderly  way.  The  definition  of  the  "core"  and  its  depth  of 
detail  will  need  to  be  refined  by  trial  and  error  with  full 
involvement  and  leadership  of  the' Services  and  Agencies.  With 
the  “core"  defined  initially  within  a  few  months,  the  Services 
can  proceed  directly  in  their  system  design  efforts  to  address 
their  own  specific  needs  rather  than  successively  reinvent  the 
central  architecture.  Thus  the  Service  design  studies  should  be 
phased  with  the  core  development. 

Since  a  number  of  elements  of  the  Phase  I  core  are  already 
known.  Service  planning  for  test  beds  to  gain  practical 
experience  with  data  exchange  standards  and  protocols  can  proceed 
without  delay,  as  can  functional  demonstrations  to  validate  user 
interfaces  and  user  data  system  designs. 


Schedule 


Task 


Responsibility 


1.  Review  NBS  Program  and  Industry  Task 

Phase  I  "Core"  Applica-  Force 

tions 


2.  Phase  I  "Core”  Require¬ 
ments  Package  (Draft) 

3.  Initial  Service 
Extensions  of  Phase  I 
Core  Package 

4.  Industry  CALS  Consortium 
Chartered 


OSD  CALS  Office, 
Service  Support 

Services,  DLA 


NSIA  Task  Force 
Chairman 


5.  Industry-proposed  Phase  II  Consortium 
Core  Requirements,  DoD 
Interfaces 


First 

Issuance 


Dec  8  6 


Feb  8  7 
May  8  7 


Jan  87 

Jun  8  8 
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CALS  IMPLEMENTATION  PLANS 


CO  ^ 
Z  h- 

o  < 


>  £ 


55 

UJ  cc 
I-  < 


LL  • 


cc 

O  Q 
O  UJ 
uj  H 
H  < 
<  Z 

°  Q 
05  CC 

z  ^ 
-  o 

Q  <-> 


r—  uj 
Z  CD 
UJ 

Q  (J 

«  1 

i-  > 

O 

uj  O 

2  > 

O  uj 


59  h 

C/5 

<1 

o  w 

^  cc 

in  < 
^  co 

CC  2 

I  5 


Q  Cl 
Z  ft 

§  5 

>  Q 


^  < 

UJ 

H-  UJ 
CO  O 

CO  s 


£  £ 

LL  UJ 

o  co 

>_  UJ 

H  H 

5  § 

s  1 

<  i 

CL  D 

°  =j 
O  — 

.  £ 


1,-29 


co  co 

1  - 

2  a 


<2  o 


-  o 

CC  LU 

a.  d. 

O  w 
H  Q 

CO  1 
CO  < 


IU  5 
2  < 


O  • 


2  < 

<  CC 

2  < 

<  °- 


2  CO 
<  CC 


<  u- 

2  2 


§  S 


Q  o 

LU  2 

X  < 
H  CC 


2  O 

2  co' 

<  UJ 

->  o 
D  o 
5  < 


CO  (J 

CO  ^ 


2  5 

o  := 


I-  o 

Hi  LU 

<  °- 
u.  Q  ^ 

D  2  z 

2  <  □ 

<  CO  UJ 

2  co  g 

as! 

W  < 

LU  5  h 

ofz 

*3.  LU 
>  .  £ 
i_  >  2 

Sts 

5  m 

<  5  tu 
K  <  I- 
CO  U  "7 

LU  LU  ~ 
I-  CC  LU 


L-30 
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APPROACH  TO  DOD-WIDE 
INTEGRATION 


PROCUREMENTS 
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Embedded  Software  View 

6.1  Software/Firware  specification 

6.2  Embedded  software  program  listing 

6.3  RQH/PLA  programming  charts 
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EDIF  Version  200  takes  on 
production  environment 

The  newly  revised  Electronic  Design  Interchange  Format  polishes 
the  old  standard  and  tries  to  meet  the  challenges  of  the  production 
environment  head-on. 


Say  goodbye  to  Version  1 10  of  the  Electronic  De¬ 
sign  Interchange  Format:  a  soon-to-be-released 
Version  200  of  the  EDIF  is  tackling  housecleaning 
chores  as  well  as  conquering  some  new  territories. 
Vowing  to  clear  up  ambiguities  in  the  document 
itself,  the  EDIF  Technical  Committee  has  been 
making  structural,  syntactical  and  semantical 
changes.  In  this  emerging  version,  even  some 
minor,  seemingly  unimportant  changes  were  made 
to  anticipate  future  needs.  Besides  this  primping 
and  polishing,  the  200  release  provides  the  founda¬ 
tion  for  upward  compatibility  between  EDIF  edi¬ 
tions,  and  perhaps  most  importantly,  stakes  out  the 
demanding,  day-to-day  design  issues  of  the  produc¬ 
tion  environment. 

The  most  obvious  changes  are  the  restructuring 
and  rewriting  of  the  EDIF  document.  The  entire 
specification  has  been  rewritten  by  a  single  author 
to  ensure  a  more  comprehensive,  cohesive  docu¬ 
ment  than  is  usually  possible  when  several  writers 
are  involved.  As  before,  a  committee  generated  the 
technical  content,  but  one  author  was  responsible 
for  pulling  all  the  facts  together.  In  addition,  many 
independent  users,  who  are  currently  working  with 
EDIF  or  will  be  involved  with  future  extensions, 
had  the  opportunity  to  comment  on  the  revision. 
Their  reviews,  coupled  with  those  of  a  full-time 
technical  editor  and  several  subcommittees,  helped 


Mika  Waters 

Waters  is  a  principal  engineer  at  Motorola 's  ASIC 
division  < Chandler ,  AZ).  He's  worked  on  the  EDIF 
Technical  Committee  since  its  founding  and  is  now 
Chairman  of  the  group. 


clear  up  obscure  or  confusing  sections  of  the  1 10 
version.  As  a  result  of  these  efforts,  the  syntax  of 
the  EDIF  text  was  extensively  reworked. 

Most  of  these  changes  are  attempts  to  make  the 
syntax  upwardly  compatible,  but  the  committee  ad¬ 
dressed  context  sensitivity  and  other  problems  as 
well.  Context  sensitivity  arises  when  a  single 
keyword  is  used  for  more  than  one  function  and  the 
semantic  interpretation  of  the  object  depends  on 
the  location  of  the  keyword  in  the  file.  Because  the 
problem  of  multiple  usages  is  often  extremely  hard 
to  resolve  without  ambiguity,  they’ve  been  remov¬ 
ed.  Of  course,  using  a  keyword  (such  as  Rename)  in 
two  or  more  places  for  the  same  function  doesn’t 
create  problems  and  occurs  frequently. 

A  major  structural  problem  in  Version  110, 
however,  is  that  the  names  of  ports  share  the  same 
namespace  as  signal  groups;  consequently,  it's  im¬ 
possible  to  define  a  port  named  “A”  and  a  signal 
named  "A"  as  two  different  objects.  As  part  of  the 
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solution,  the  keyword  Define  was  removed.  A  more 
systematic  object-naming  scheme,  and  a  universal 
rule,  called  Define-before-use,  replaces  the  original 
keyword. 

In  an  object-naming  scheme,  many  of  the  key¬ 
words  are  closely  related  to  actual  or  abstract 
design  entities  such  as  an  1C  part.  Since  the  design 
object  has  a  definite  and  unique  reference  name 
within  the  design,  this  name  is  reflected  within  the 
ED1F  File.  A  formal  method  has  been  devised  to 
point  to  the  name  unambiguously  from  anywhere 
in  the  file.  This  naming  of  objects  is  commonly 
used  in  data  bases  and  description  languages  as  well 


Cora  group  develops  standards 

raditionaily,  standards  can  taka  many  years  to 
develop.  By  selecting  a  small  group  of  higniy 
motivated  specialists  from  a  small  number  of  or¬ 
ganizations  to  generate  and  test  trie  first  drafts  of 
the  standard,  me  EDIF  developers  elected  to  fol¬ 
low  a  somewhat  unusual  course.  Because  the  elec¬ 
tronics  industry  changes  rapidly,  particularly  the 
CAE/CAO  sector,  the  EDIF  Technical  Committee 
wanted  to  arrive  at  a  standard  quickly.  To  achieve 
results  tnat  would  not  take  so  long  that  they  would 
become  obsolete  while  still  in  the  development 
stage,  the  group  that  directed  the  initial  work  was 
a  small,  stable  core  ot  people. 

When  it  came  time  to  discuss  long-term  strat¬ 
egy.  however,  more  people  had  to  be  involved.  The 
current  procedure  still  allows  for  continual  review 
and  extension,  put  with  more  people  to  coordinate, 
adding  a  new  feature  or  caoability  is  a  bit  more 
complex.  First,  all  new  proposals  originate  from 
one  of  the  Technical  subcommittees.  When  a  sub¬ 
committee  is  satisfied  that  it  has  found  a  viable 
solution,  it  makes  a  formal  proposal  to  the  EOIF 
Technical  Committee. 

Next,  the  Technical  Committee  reviews  the  pro¬ 
posal,  suggests  any  changes  it  thinks  are  needed 
and  makes  sura  that  the  other  subcommittees  are 
aware  of  the  impact  of  proposed  changes  on  their 
work.  Normally  this  review  takas  place  during  a 
meeting  between  the  Technical  Committee  and  all 
ol  the  subcommittees.  Once  the  review  is  com¬ 
pleted,  a  trial  document  is  published  in  conjunc¬ 
tion  with  the  next  major  releasa  of  the  complete 
specification. 

Although  the  time  and  amount  ot  testing  varies 
with  the  complexity  of  the  proposal,  ail  trial  docu¬ 
ments  see  actual  use  before  receiving  approval,  if 
accepted,  the  new  capabilities  are  incorporated  in 
a  draft  of  the  complete  specification,  which  is  cir¬ 
culated  to  all  subcommittees  as  well  as  to  a  small 
community  of  reviewers.  Alter  an  intense  review, 
the  committee  issues  a  major  release.  This  can  be 
viewed  as  a  pipeline  operation.  With  every  release, 
there's  a  new  crop  of  extensions  and  proposals 
published  as  trial  extensions,  as  well  as  proposals 
that  are  still  in  the  preliminary  stages. 


as  in  the  1 10  version.  The  200  release,  however,  im¬ 
proves  this  procedure,  adding  more  regularity  and 
consistency. 

Any  keyword  with  a  named  identifier  is  defined 
to  create  (Namedef)  or  to  reference  a  name 
(Nameref).  The  creation  of  a  name  also  gives  rise  to 
a  new  (hidden)  namespace  so  that  the  name  can  be 
referenced  from  outside  its  own  space  as  in  previous 
EDIF  versions. 

Meanwhile,  Define-before-use  anticipates  and 
resolves  many  potential  problems.  One  of  its  useful 
functions  is  that  it  eliminates  the  possibility  of 
creating  either  instance  or  name  reference  loops. 
Since  the  names  are  all  defined  at  a  higher  level  of 
the  hierarchy,  this  nondefauit  reference  mechanism 
doesn’t  prevent  users  from  including  graph-type 
cro's  references. 

As  part  of  the  general  cleanup,  a  standard  order¬ 
ing  of  arguments  has  been  adopted  and  symbolic 
constants  have  been  either  removed  or  isolated 
within  a  special  keyword.  The  committee  also 
defined  a  new  property  mechanism  and  developed 
a  generic  identifier  that  renames  or  displays  an  ob¬ 
ject  name. 

Semantic  changes 

Looking  at  revisions  to  EDIF  semantics,  views  such 
as  Masklayout  and  Symbolic  were  untouched, 
whereas  Net  List  and  Schematic  saw  major  addi¬ 
tions  and  modifications.  Although  the  Behavior. 
Document  and  Stranger  views  have  no  addition  as 
yet,  some  pans  have  been  removed  on  a  trial  basis. 
New  views,  focusing  on  some  new  features,  include 
Pcblayout,  which  targets  the  layout  problems  of 
printed  circuit  boards.  It’s  similar  to  a  Masklayout 
view  aimed  at  integrated  circuits.  EDIF  200  also 
boasts  a  view  with  "dumb”  or  annotaiive  graphics, 
such  as  logos,  page  borders  and  copyright  notices, 
called  Graphic. 

Another  major  revision  is  the  introduction  of 
multiple-page  schematics  as  a  page  construct  in  the 
Schematic  view.  Using  this  modified  view,  an  off- 
page  connector  can  be  viewed  as  a  port-like  object, 
which  can  be  referenced  only  within  the  contents  of 
the  cell.  Because  the  name  can  be  referenced  by 
every  page  within  the  contents,  all  page  connectors 
can  be  joined  with  the  same  name  in  the  cell.  En¬ 
gineers  wilt  also  be  able  to  handle  reference  designa¬ 
tors.  This  feature  is  commonly  used  in  the  design  of 
printed  circuit  boards. 

Committee  members  restructured  the  Net  List 
view  even  more  than  the  schematic  section.  Remov¬ 
ing  Signaigroup,  they  then  added  a  true  net  con¬ 
cept,  which  includes  the  ability  to  define  * 
bus-and-bundie  object.  With  the  new  net  concept. 
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users  can  associate  special  graphics  with  these  ob¬ 
jects.  Because  the  properties  of  a  bus  or  bundle  ex¬ 
ist  independently  of  any  graphics  associated  with 
the  connector,  a  locally  standard  symbol  may  be 
substituted  for  the  original  graphics  without  losing 
information. 

Ensuring  upward  compatibility 

Upward  compatibility  between  EDIF  versions  is 
one  of  the  major  issues  concerning  production 
readiness.  This  is  especially  important  with  a  for¬ 
mat  such  as  EDIF,  which  must  change  and  grow  as 
the  underlying  technology  evolves.  Version  200  is 
expected  to  allow  limited  upward  compatibility  in 
the  near  future.  The  pLi  is  to  designate  certain 
keywords  and  groups  of  keywords  as  upwardly 
compatible  or  frozen.  While  much  of  EDIF  Version 
200  appears  to  meet  the  necessary  criteria,  the  ver¬ 
sion  must  be  thoroughly  tested  in  actual  use  before 
this  can  be  proven  with  any  confidence. 

Upward  compatibility  can  be  interpreted  in  a 
number  of  ways.  For  EDIF  it  means  that— subject 
to  certain  restrictions— software  for  future  EDIF 
versions  can  read  and  correctly  interpret  design 
data  of  older  EDIF  versions.  Easing  the  transition 
from  one  version  to  another,  this  level  of  upward 
compatibility  provides  a  stable  base  to  explore  and 
exchange  research-oriented  data. 

Of  more  interest  to  industrial  users,  however,  is 
design  flexibility.  With  an  upwardly-compatible 
standard,  these  users  need  the  hardware  and  soft¬ 
ware  of  the  earlier  design  for  future  revisions.  In¬ 
stead,  modern  design  tools  can  revise  the  archived 
edition. 

A  number  of  rules  must  be  followed  by  all  parties 
to  ensure  that  both  complete  and  accurate  interpre¬ 
tation  of  the  design  information  will  occur.  Several 
of  the  most  important  restrictions  apply  to  the  soft¬ 
ware  that  writes  the  EDIF  file.  User-defined  exten¬ 
sions,  such  as  Userdata  or  User  properties,  can't  be 
used.  Since  their  semantic  definition  is  set  entirely 
by  agreement  between  third  parties,  these  exten¬ 
sions  or  properties  may  be  considered  obsolete  at 
any  time. 

Care  must  also  be  taken  to  ensure  that  semantic 
and  syntactic  extensions  preserve  the  validity  of  the 
earlier  EDIF  version.  One  of  the  most  obvious  rules 
is  that  revisions  can’t  delete  keywords  that  are  cur¬ 
rently  defined.  On  the  ocher  hand,  it  would  not  be 
desirable  to  have  so  many  keywords  that  a  high 
percentage  rarely  serve  a  purpose. 

In  response  to  these  potential  problems,  the  revi¬ 
sionists  altered  the  structure  of  the  older  1 10  as  well 
as  the  200.  Some  limits  are  mostly  stylistic;  syntax 
for  keywords,  for  example,  must  be  consistent 


throughout  the  text  and  conform  to  the  underlying 
structural  model,  or  meta-syntax,  so  that  system¬ 
atic  analyses  can  be  performed  during  review.  By 
far,  most  of  the  syntax  changes  for  Version  200  fall 
into  this  category. 

Another  class  of  changes  involves  fixed  or  re¬ 
quired  fields.  They  must  now  appear  in  the  follow¬ 
ing  order;  name  define,  name  reference^),  required 
fields  in  fixed  positions  and  optional  structures, 
which  may  appear  in  any  sequence.  To  maintain 
upward  compatibility,  only  optional  fields  can  be 
added  to  any  previously  defined  construct.  Simi¬ 
larly,  a  field  that  is  currently  optional  can’t  later  be 
made  mandatory. 

Fortunately,  however,  adding  optional  fields 
isn't  difficult.  And  tacking  on  required  fields  after 
a  structure  has  been  defined  is  rarely  necessary. 
When  such  an  addition  is  needed,  it's  caused  by 
some  fundamental  change  in  the  underlying  seman¬ 
tics  of  the  construct  and  should  be  handled  by  ad¬ 
ding  a  new  construct.  Upward  compatibility,  by 
making  it  impossible  to  simply  change  an  old  con¬ 
struct,  just  forces  users  to  analyze  the  situation 
more  carefully. 

Implications  of  ordering 

Coming  to  terms  with  the  semantic  implications  of 
ordering  has  more  subtle  traps.  In  this  case,  addi¬ 
tional  or  changed  technology  can  require  more 
semantics.  Unfortunately,  these  semantics  can't  be 
added  without  damaging  the  existing  format.  For 
this  reason,  the  list  of  optional  fields  is  always  a  sin¬ 
gle  string  with  more  keywords  added  to  make  any 
interpretation  syntactically  explicit  regardless  of 
ordering.  Sometimes,  however,  keywords  are  de¬ 
fined  that  contain  only  one  or  two  objects  with  a 
semantic  interpretation  that  is  obvious  to  current 
technology  without  the  keyword. 

For  engineers  who  develop  interface  software  for 
EDIF,  upward  compatibility  provides  other  advan¬ 
tages.  Since  the  software  that  created  an  EDIF  file 
is  usable  for  a  longer  period  of  time,  much  of  the 
work  involved  with  revising  an  interface  to  a  new 
version  is  spared.  The  software  that  reads  the  file 
will  have  to  be  modified  for  the  new  revision, 
however,  since  information  contained  in  new  key¬ 
words  would  be  lost  and  the  user  would  have  no 
way  to  determine  its  importance. 

While  the  changes  are  quite  extensive,  some  care 
has  been  taken  to  minimize  the  overall  impact  on 
existing  code.  The  most  extensive  modifications  oc¬ 
cur,  in  fact,  at  a  very  low  level  of  structuring  (order¬ 
ing,  for  example).  As  a  result,  the  majority  of  the 
changes  should  be  possible  without  extensive  soft¬ 
ware  revisions. 
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The  lesson  of  the  Swiss  cheese  makers 

Ttis  is  a  story  about  some  cheese  makers  who  never  tried  before),  as  specified  by  the  customer's 
created  a  method  to  exchange  the  specs  of  CAO  system.  Only  then  was  it  discovered  that  the 


their  cheeses.  The  cheeses  came  in  two  shapes: 
square  and  flat.  Some  had  round  holes,  some  had 
oval  holes  and  some  had  no  holes  at  all.  To 
describe  these  features,  the  cheese  makers  de¬ 
veloped  the  Cheese  Definition  interchange  Proto¬ 
col  ,  popularly  known  oy  >ne  partial  acronym 
CheeseDlP.  Based  on  a  usp  syntax  it  looked 
something  like: 

(CheeseOIP  (Square  ...)  (Round  ...) ...) 
or 

(CheeseDlP  (Flat ...)  (Oval ...) ...) 

This  defined  exactly  the  type  of  cheese,  and  was 
formalized  into  the  meta-syntax: 

CheeseOIP  ::  =  (cheese|  (holesl 
Cheese  ::  =  SOUARE/FLAT 
Holes  ::  =  ROUNOfOVAL. 

With  this  syntax,  any  number  of  cheeses  could 
be  specified  m  any  combination  of  legal  shapes, 
with  any  number  of  holes,  it  even  was  possible  to 
combine  round  and  oval  holes  for  special  orders. 
But  the  syntax  overlooks  one  obvious  point:  The 
square  and  flat  charactenstics  make  sense  only 
for  (he  shape  of  cheeses,  not  holes. 

When  someone  invented  a  process  that  pro¬ 
duced  square  holes.  CheeseOIP  had  to  be  extend¬ 
ed:  Holes::  =  ROUND/OVAUSQUARE.  Almost  at 
once  an  order  was  received  for  a  cneese  that  look¬ 
ed  like  this:  (CheeseOIP  (Flat  ...)  (Square  ...) 
(Round...)). 

At  great  expense,  a  single  flat  cheese  was  made 
with  both  square  and  round  holes  (a  novel  variation 


Version  200  is  certainly  not  the  end  of  EDIF  de- 
veopmem.  Rather,  it’s  the  end  of  the  beginning. 
Each  technical  subcommittee  has  prepared  pro¬ 
posals  that  must  now  be  tested  with  real  designs 
before  inclusion  in  the  next  version  of  EDIF.  Cur¬ 
rently,  there  are  proposals  concerning  behavioral 
modeling,  physical  design  rules,  procedural  exten¬ 
sions  and  process-dependent  descriptions.  In  keep¬ 
ing  with  EDIF’s  development  philosophy,  this 
testing  will  be  conducted  by  those  organizations 
that  need  the  features  badly  enough  to  expend  the 
effort  and  take  the  risks. 

EDIF  looks  ahead 

The  future  plans  from  subcommittees  are  in  various 
stages  of  development  and  review.  The  ongoing 
testing  and  reviewing  of  proposals  slated  for  trial 
use  is  one  of  the  major  priorities.  Most  of  the  pro¬ 
posals  in  the  trial-use  document  will  be  incor- 
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customer  bad  really  wanted  two  quite  ordinary  and 
inexpensive  cheeses— a  flat  cheese  and  a  square 
cheese  with  round  holes! 

Unfortunately,  it's  not  possible  to  include 
square  holes  at  this  point  because  it  won't  be 
recogmzea  by  the  older  version  ol  CheeseDlP.  The 
strange  keyword  Squarehole  could  be  used,  but 
this  would  quickly  lead  to  a  huge  number  of 
strange  keywords  defined  with  identical  seman¬ 
tics.  Most  would  be  used  in  only  one  specific  ap¬ 
plication  or  not  at  all.  To  introduce  keywords  for 
cneese  and  holes  or  impose  some  other  form  of 
ordering  would  make  older  files,  which  were  wnt- 
ten  without  these  new  rules,  obsolete. 

The  moral  of  the  story  is  that  even  though  a  stan¬ 
dard  may  have  a  well-defined  set  of  contained  oo- 
tacts  and  may  suit  current  technology  perfectly, 
anticipating  the  needs  of  future  technologies  is 
more  difficult.  EDIF.  therefore,  must  avoid  any 
similarly  implied  assumptions  and  maintain  a 
close  correspondence  between  keywords  and  ob- 
tects— despite  the  fact  that  current  techology 
doesn't  require  such  fine  distinction. 

In  addition,  the  use  of  any  order-dependent  list 
imposes  rigidity  upon  a  structure  that  can  hide 
deeper  problems.  To  the  casual  user,  this  intro¬ 
duces  many  extra  keywords,  which  serve  only  to 
contain  one  or  two  other  keywords.  The  other 
possible  consequence  is  a  random  ordering  for  ob¬ 
jects  that  can  be  confusing  and.  in  any  event,  serve 
no  purpose  in  the  context  of  current  technology. 

By  Paul  Stanford,  a  senior  software  engineer  and 
Texas  Instruments'  representative  to  the  EDIF  Tech¬ 
nical  Committee 


porated  in  the  next  EDIF  release.  This  includes  the 
behavioral  proposal,  which  attempts  to  provide 
transportable  models  and  to  produce  accurate 
results  on  a  large  number  of  simulators.  Also  in¬ 
cluded  is  the  physical  design-rule  proposal,  which 
will  provide  the  means  to  move  automated  design- 
rule  checking  between  design-verification  software. 

Once  the  current  proposals  for  physical  design 
rules  are  finished,  the  subcommittee  expects  to  ad¬ 
dress  the  problems  of  electrical  design  rules.  This 
will  include  rules  for  the  maximum  current  density 
of  ICs  and  limits  on  voltage  levels. 

Aside  from  the  efforts  of  these  groups,  a  new 
subcommittee  will  examine  the  problems  of  printed 
circuit  board  layout.  The  earliest  work  in  EDIF  was 
oriented  toward  the  problems  of  IC  technology 
The  new  committee  will  investigate  the  handling  of 
design  data,  and  to  a  lesser  extent,  the  treatment  of 
manufacturing  and  maintenance  information. 
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How  do  I  get  started? 

To  team  more  about  Version  200,  write  to  the 
EDIF  User  Group,  2222  S  Dobson  Rd,  Bldg  S, 
Mesa  A 1  95202.  No  telephone  calls  please.  Work¬ 
shops  and  tutorials  concerning  the  standard  are 
another  source  of  information.  Some  are  offered 
during  the  Oesign  Automation  Conference  and  the 
international  Conference  on  Computer  Aided 
Oesign.  These  workshops  are  one  of  the  best  ways 
to  hear  about  the  latest  developments  and  ac¬ 
tivities  and  to  talk  with  some  of  the  subcommittee 
members. 

Another  option  is  to  become  a  member  of  one  of 
these  groups.  By  participating  in  a  subcommittee, 
you  can  keep  abreast  of  the  most  recent  informa¬ 
tion,  learn  more  about  implementation  problems 
and  influence  the  features  and  development  of 
EDIF.  Most  of  the  subcommittees  meet  monthly  or 
bimonthly  at  locations  convenient  to  their  mem¬ 
bership. 

Another  group  is  examining  the  problems  asso¬ 
ciated  with  the  EDIF  representation  of  schematic 
drawings,  starting  with  validation  and  testing  of  the 


current  EDIF  schematic  capability.  At  the  same 
time,  a  multinational  subcommittee,  made  up  of 
participants  from  both  the  United  States  and  Euro¬ 
pean  countries,  is  examining  the  problems  involved 
in  the  transfer  of  test  information.  This  is  expected 
to  cover  both  interfaces  to  automated  testers  as  well 
as  more  complex  issues  such  as  test  generation  and 
procedural  testing.  CO 


Please  rale  the  value  of  this  article  to  you  by 
circling  the  appropriate  number  in  the  "Editorial 
Score  Box"  on  the  Inquiry  Card. 
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This  request  Is  for  yog,  t  colleague,  or  your  employee  to  contribute 
4  man-weeks  of  technical  expertise  to  a  team  effort  toward  a  common  Information 
model  for  electrical  products.  The  expertise  needed  by  the  team  is  the 
computer  applications  engineer  who  has  been  Involved  In  support  of  design, 
analysis  or  manufacturing  of  your  Integrated  circuit,  printed  wiring  board 
or  harness  products. 

As  a  person  Involved  In  computer  aided  Integration  of  electrical 
product  development,  you  can  appreciate  the  size  of  the  task.  There  are 
many  vendor  systems,  several  data  transfer  formats,  and  your  company  concept 
of  a  design/tooling  data  storage  organization.  The  members  of  the  task 
team  expect  to  benefit  from  the  collective.  Intensive,  full-time  Identification 
and  documentation  of  the  related  Information  involved  In  our  data  systems. 

With  the  common  Information  model  as  a  road-map,  appropriate  structuring 
or  mapping  to  your  own  physical  data  structure  will  require  significantly 
shorter  project  completion  schedule.  Further,  cooperation  with  the  applicable 
neutral  transfer  formats  will  establish  known  Information  capabilities 
and  encoding  guidelines. 

The  attached  form  Indicates  the  dates  Involved  and  can  be  used  to 
reserve  a  place  on  the  team.  During  the  January  5  through  February  27, 

1987  schedule,  only  12  technical  expert*  positions  are  offered  to  keep 
the  team  size  appropriate  to  effective  work.  The  team  Is  responsible 
to  the  IEEE  Design  Automation  Standards  Subcommittee,  and  the  NBS  Product 
Data  Exchange  Specification  organizations.  Thus  the  meetings  of  the  team 
are  open  If  you  wish  to  attend  Informally.  Note  also  that  one  week 
is  reserved  for  training  In  the  modeling  technology  (IDEFiX).  All  team 
meetings  will  be  at  the  Engineering  Building  and  at  Kellogg  West  Conference 
Center  on  the  campus.  Lodging  is  available  at  Kellogg  West  and  nearby 
hotels. 

Time  is  critical  for  the  organization  of  this  Important  activity; 
please  Identify  the  appropriate  area  of  your  organization  and  person  to 
best  advise  and  return  knowledge  of  our  connon  Information  model. 


for  the  Cal  Poly  Task  Team 
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To:  Marcia  lannone 

Standards  Task  Team 

California  Stata  Polytechnic  University 
Dtpt.  of  Electronics  and  Computers  Engineering 
3801  Mast  Temple  Avenue 
Pomona,  CA  91788-4065 

Plaasa  Includa  the  following  technical  specialist  In  your  consideration 
for  Task  Team  members.  We  understand  that  as  a  sponsoring  orgmlzatlon,  we 
art  responsible  for  continuing  salary  for  4  weeks  (total)  for  our  accepted 
team  member. *  We  further  agree  to  release  any  sponsored  member's  work  com¬ 
pleted  while  on  the  Task  Team. which  work  shall  be  considered  public  domain 
and  publishable  by  the  IEEE. 

Technical  Specialist _ Manager _ 

Organization  Address_ _ _ _ Address  (If  different)  _ _ 


Telephone 


Telephone 


Date _ Signed 


Date _  Signed 


_ _  Yes,  Include  me  In  your  January  5-9,  1987  Tools  Training. 

_  I  prefer  the  January  19  through  February  6  Information  modeling  session. 

_  I  prefer  the  February  9  through  27  information  modeling  session. 

In  addition  to  participation,  reviews  are  scheduled  to  present  the  Infor¬ 
mation  model  and  receive  Industry  comments.  For  review  Interest  only,  fill 
In  your  neme  end' address  as  technical  or  manager,  and  check  the  appropriate 

dates: 

_  Boston  area,  March  10-13  (4  days),  review  and  workshop. 

_ _  San  Francisco  bay  area,  March  23-27  (5  days),  review  and  workshop. 

_  Wrlght-Pattarson  AFB,  April  13-17  (5  days)  presentation  and  physical 

database  mapping  workshop. 


•Funds  may  be  available  to  offset  travel  and  lodging  costs.  For  Information 
call  Professor  Richard  Cockrum,  (714)  869-2511. 


IPC 


•  Trade  Association 


Formed  in  1957  by  six  printed  board  manufacturers. 


•  1 ,400  member  companies—  1 986 

-Regular 

-  28% 

-Allied 

-  35% 

—Associate 

-  31% 

—Government  &  Tech.  Liaison 

-  6% 

•  International  Scope 

-Americas 

-  71% 

-Europe 

-  13% 

-Australasia 

-  14% 

-Other 

-  2% 

All  standards/specifications  sent  for  approval  to  all  IPC  official  representatives. 


PROBLEMS 

•  Too  much  implementation  flexibility. 

•  Minimal  support  by  CAD  system  vendors. 

•  Industry  usage  abuse 

-DoD  contract  horror  stories 
-Equipment/not  data. 

•  Inadequate  IPC  training  programs. 

•  Experience  of  tri-Service  personnel. 

•  Public  domain  translator. 
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LONG  RANGE  OBJECTIVES 


Complete  definition  of  electronic  assembly. 
Design  -  Manufacturing  -  Test  -  Hard  Copy 


IPC-D-354 


IPC-D-352 


IPC-D-350B 


IPC-D-351 


IPC-D-353 


EXTERNAL  LIBRARY 


INTERNAL  LIBRARY 


ELEC.  DESCRIP. 


BILL  OF  MATL 


PHOTO  TOOLING 


BOARD  DESC 


SCHEMAOGIC  DWG 


MASTER  DRAWING 


ASSY  DWG 


PART  DWG's 


TEST  DESCRIP. 


} 

} 

} 


> 
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IMPLEMENTATION  HISTORY 


•  Revision  A  released  1975. 

—First  contract  issued 

-Industry /DoD  coordination  meetings 

-ANSI  approval 

•  Revision  B  started 

-Allowed  more  flexibility 
-Removed  standard  font 
-Removed  standard  land  patterns 
-Simplified  for  small  company  use 

•  Coordinated  through  ANSI  Y  14.26  Committee. 

•  Approved  for  use  by  DoD 

—Required  by  MIL-STD-275 
—Required  by  MIL-STD-21 18 

•  Five-year  no-change  policy 

•  Major  user  -  NSA 

-Contract  tailoring 
-Input  to  IPC  Committees 

•  Submitted  by  US  to  IEC 

— 52(U.S.A.)  122 

•  Coordination  with  ICER. 
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